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ABSTRACT 



Disclosed is a system for accessing a folder of messages in 
a mail server, such as an inbox folder, outbox folder, draft 
message folder, etc. This disclosed system is especially 
suited for "offline" type protocols, such as POP3. A client 
computer estabhshes a first connection with a mail server 
including the folder of messages over a network. The client 
computer communicates a command to the mail server to 
parse messages in the folder to obtain message headers. The 
message headers are then downloaded to the client com- 
puter. After downloading the message headers, the first 
connection between the client computer and the mail server 
is terminated. The chent computer may then be used to select 
at least one displayed header. After message headers arc 
selected, a second connection is established between the 
cheat computer and the mail server. The client computer 
communicates a command to the mail server to retrieve a 
body for each message whose header was selected. The 
selected message bodies are then downloaded to the cHent 
computer. After downloading message bodies, the client 
computer communicates a command to the mail server to 
delete the selected messages from the folder in the mail 
server. The client computer then communicates a command 
to the mail server to terminate the second connection 
between the client computer and the mail server. 

23 Claims, 6 Drawing Sheets 



30 



CUENICOMm 



MS BROWSER 



CflMFOSEfAGE 



COMPOSE 

mm 



VIEWmE 



VIEW 
APPIET 



MAINU/ULmE 



MAIIAPPIE] 



lOCAiflnpsEmn 




ronoFFiCi 

CACSE 



NIIWOHI 




08/28/2003, EAST Version: 1.04.0000 



U.S. Patent Sep. 14,1999 Sheet lore 5,951,636 



a- 





POST OFFICE 
SYSIEM 



flG.1 



10- 




14 






P0F3PR0r0CQl 


SIHVER 


) 







v 



18 



•16 



P08T0FFIC[ 



FIG. 2 



08/28/2003, EAST Version: 1.04.0000 



U.S. Patent Sep. i4, 1999 sheet 2 of 6 5,951,636 



^ 



CLIENT COMPUTER 



38 



WEBBROWSER 



31- 



C OMPOSEPAGE 

COMPOSE 
APPLET 



-42 



VIEW PAGE 

VIEW 
APPLET 



■44 



■50 



MAIN MAIL PAGE 



MAIL APPLET 



LOCAL HHP SERVER 



55- 



JAVA 
CACHE 



■52 



-46 



-411 



POSTIlfflCE 
CACHE 



-54 



NETWORK 





MAIL SERVER 



Mi 
PROT 


III 

OCOl , 











■62 



•64 



POSTOFflCE 
SrSTEM 



FIG. 3 



08/28/2003, EAST Version: 1.04.0000 



U.S. Patent Sep. i4, 1999 sheet 3 of 6 5,951,636 






WAIIFOR 
USER 10 ACCESS 
POSI OFFICE fROM 
BHQWSER. 




92 



CUENieHOWSER 
IRANSFERSflEaUESI 
TO HHP SERVER VIA 

1HEUE1W0RK. 



\ 

HHP SERVER PROCESSES 
REQUESIAND RETRIEVES 
ANOOOWNIIIADSAJAR 
fllEOFAPPlETSlOTHE 
BROWSER FOR STR0A6E 
IN THE JAVA CACHE. 



WEBBROWSER 
OPENS MAIN 
MAIL PAGE AND 
MAIl APPLET THEREIN. 



100 



MAILAPPLH 
STARTS THREAD 
TO RUN THE 
HHP SERVER. 



102 



MAIL APPLET 
DISPLAYS LOGIN 

SCREEN IN 
MAIN MAIL PAGE. 



m 



MAIL APPLET 
OPENS CONNECIN 
WITH MAIL SERVER TO 

PROVIDE USER 
LOGIN INFORMATION. 






YES 






110 


r 




112 
S 


MAIL APPLO OPENS 
CONNECTION WITH POST 
OFFICE SYSTEM USING 
MAIL PROTOCOL. 


—* 


DISPLAY MAIN 
MAIL PAGE IN 
WEBBROWSER. 




lU 



HAS USER 
SEUCTED VIEW OPTION 
TO VIEW FILES 
IN POST OFFICE 




116 



MAIL APPLET FUNCTIONS 
AS FILE VIEWER ALLOWING 
USER TO VIEW FILES IN 
POST OFFICE SYSTEM. 



FIG.4A 



08/28/2003, EAST version: 1.04.0000 



U.S. Patent 



Sep. 14, 1999 



Sheet 4 of 6 



5,951,636 




130 

A 



WAIirOH 
UStRTOSELECf 
fllEINlHEPOSI 
OFFICE SYSTEM. 




132 



MAIL APPLE! CALLS 
SHOWOOCUMENITO 
CAUSE WEB BROWSEfl 
10 OPEN A VIEW PAGE 
INCLUOINGSELECTEO FILES 
HAVING A URL IN THE 
LOCAL HTTP SERVER 
AND THE VIEW APPLET. 



136 
\ 



WEB BROWSER REQUESTS 
LOCAL HTTP SERVER FOR 

SELECTED FILES TO 
DISPLAY IN VIEW PAGE. 



13B 



LOCAL HnP SERVER PASSES 
BEQUESTTOMAILAPPLET. 



144 




U2 



MAIL APPLET OBTAINS 
REQUESTED FILES FROM 
POST OFFICE CACHE. 



MAIL APPLET ACCESSES 
MAIL SERVER AND POST 

OFFICE SYSTEM TO 
OBTAIN REQUESTED FILE. 



REOOESTED FILES IN 
POST OFFICE SYSTEM 
DOWNLOADED TO POST 
OFFICE CACHE FOR 
STORAGE THEREIN. 



148 
\ 


r 


MAILAPPLET ASSEMBLES 


HTMLTEMPLATE INCLUDING 


REQUESIED 


MAIL FILE. 



150 



MAIL APPLET PASSES 
ASSEMBLED HTML TEMPLATE 
TO LOCAL HnP SERVER. 



152 



LOCAL HTTP SERVER PASSES 
ASSEMBLED TEMPLATE 
TO WEB BROWSER TO 
DISPLAY VIEW PAGE 

INCLUDING SELECTED FILE. 



FIGJB 



08/28/2003, EAST Version: 1.04.0000 



U.S. Patent 



Sep. 14, 1999 



Sheet 5 of 6 



5,951,636 



160 

WAIT FOR 
USEBIOSELECIA 
COMPOSE OPERATION 
FROM THE MAIN 
MAIL PAGE on 
VIEW PAGE. 




m 
A 



VIEW APPLET OR WIAIl APPLET 
SENDS A COMMAND TO LOCAL 
HTTP SERVER 10 INVOKE THE 
USER SELECTED COMPOSE 
OPERATION. 



164 



LOCAL HTTP SERVER 
SENDS COMMAND TO 
MAIL APPLET. 



166 

A 



MAIL APPLET ASSEMBLES 
COMPOSE PAGE INCLUDING 
TAG TO LOCATION OF 
COMPOSE APPLET. 



ASSEIUeiEO COMPOSE 
PAGE SENT TO LOCAL 
HTTP SERVER. 



T]0 
A 



LOCAL HHP SERVER TRANSFERS 
COMPOSE PAGE TO WEB BROWSER 
WHICH DISPLAYS COMPOSE PAGE AND 
RUNS COMPOSE APPLET THEREIN. 



1J2 
A. 



USER PERFORMS COMPOSE 
OPERATION IN COMPOSE 
PAGE AND SELECTS OPTION 
TO SEND COMPOSED MESSAGE 
TO THE POST OFFICE SVSTEM. 



174 
A 



COMPOSE APPLET 
TRANSFERS SENT MESSAGE 
TO LOCAL HnP SERVER. 



116 

A 



LOCAL HnP SERVER 
PASSES SENT MESSAGE 
TONIAILAPPLET. 



178 
A 



MAIL APPLET TRANSFERS 
COMPOSED MESSAGE TO 
POST OFFICE SYSTEM 
FOnTRANSMinALTO 
RECIPIENT. 



FIG.4C 



08/28/2003, EAST Version: 1.04.0000 



U.S. Patent Sep. 14, 1999 Sheet 6 of 6 5,951,636 



18D 



WAIT FOR MAIL 
APPLET TO OPEN 
CONNECTION WITH 
THE MAIl SERVER. 




1112 

V_ 

MAIL APPLET ISSUES 
P0P3 COMMAND TO 

MAIL SERVER TO PARSE 
MESSAGES IN INBOX 
TO OBTAIN MESSAGE 
HEADERS. 



MAIL SERVER TRANSMITS 
MESSAGE HEADERS 
TO MAIL APPLET. 



A. 



MAIL APPLET TERMINATES 
CONNECTION m MAIL 
SERVER OPON RECEIVING 
MESSAGE HEADEHS. 



MAIL APPLET OlSPLAYS 
MESSAGE HEADERS IN 
MAIN MAIL PAGE. 




T9D 
A 



WAIT FOR USER \ 
TO SELECT TO VIEW \ 
ONE OF THE DISPLAYED / 
MESSAGE HEADERS. / 



192 



ySER SELECTION 
COMMUNICATED 
TO MAIL APPLET. 



194 
A. 



MAIL APPLR OPENS 
COMMUNICATION WITH 
MAIL SERVER AND 
REQUESTS MESSAGE 
BODIES FOR USER 
SELECTED MESSAGES. 



196 
A 



REQUESTED MESSAGE 
BODIES DOWNLOADED 
TO MAIL APPLET. 



198 
A 



MAILAPPLET ISSUES COMMAND 
TO DELETE MESSAGES WHOSE 
BODIES WERE DOWNLOADED 

UPON TERMINATING CONNECTION. 



200 
A 



MAIL APPLET TERMINATES 
CONNECTION, MESSAGES 
MARKED DELETED ARE 
OELEIEO. 



202 
A 



MAIL APPLET TRANSMITS 

MESSAGE BODIES 
TO VIEW APPLET WHICH 
DISPLAYS MESSAGE BODIES 
IN VIEW PAGE. 



FIG. 5 



08/28/2003, EAST Version: 1.04.0000 



5,951 

1 

ACCESSING A POST OFFICE SYSTEM 
FROM A CLIENT COMPUTER USING 
APPLETS 

CROSS-REFERENCE TO RELATED s 
APPLICATIONS 

This application is related to the following co-pending 
and commonlyassigned application: 

Application Ser, No. 08/985,428, filed on the same date jq 
herewith, by Kevin G. Zerber, entitled "Inter-Applet Com- 
munication Within a Web Browser," attorney's docket num- 
ber L09 -97-035, which is incorporated herein by reference 
in its entirety. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates generally to a system for 
accessing a post office system with a remote computer using 
downloaded applets and, more specifically, to a system for 
selectively downloading messages from the post office sys- 
tem. 

2. Description of the Related Art 

An electronic post office system maintained within a ^5 
network file server allows multiple computer users linked to 
the network file server to transmit electronic messages to 
each other. A message is the basic unit of exchange in the 
post office system. A message can include file attachments 
such as text, graphics, sounds, binary files, electronic forms, 3^ 
fax pages or any other data objects. The post office is the 
central repository for all messages and is typically imple- 
mented in a database system in the network file server. The 
post office has a mail directory, which lists all the people, 
post offices and gateways for message exchange. Each user 35 
maintains an individual mailbox within the post office 
system, which might include an inbox of incoming 
messages, drafts of text messages not yet sent, an outbox of 
sent messages, trash folders of deleted messages, etc. Each 
user in the post office system has an assigned name which is 
used to identify and route mail to the user. 

FIG. 1 illustrates how cUent computers 2a, 2b access a 
post office system 4 within a server computer 6 via a 
network connection 8 (e.g., LAN, WAN, etc.). FIG. 2 
illustrates how a computer 10 at a remote location can 45 
connect to a post office system 20 via a TCP/IP connection 
12 and the Internet 14. The post office system 20 is included 
in a server 16 which runs the P0P3 protocol 18. A protocol 
is used to regulate communication between the client com- 
puter and the post office system. Protocols which regulate 50 
the flow of messages to a post office system via the Internet 
include the Post Office Protocol version 3 (POPS), as shown 
in FIG. 2, the Internet Message Access Protocol version 4 
(IMAP4), Lightweight Directory Access Protocol (LDAP), 
etc. Both the client and post office system must use com- 55 
patible protocols. For instance, software programs such as 
Netscape Navigator, Eudora Pro, and Microsoft Internet 
Explorer include the P0P3 protocol, thereby allowing a 
client computer running these programs to access a post 
office system compatible with P0P3. 

In prior art systems, the client computer must include 
software using a mail protocol compatible with the protocol 
for the post office system. Thus, if a client computer has 
software running the P0P3 protocol, but not IMAP4, then 
such client computer will not be able to access a post office 65 
server only compatible with IMAP4. Prior art systems thus 
require users to make sure that they have installed software 
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including a protocol compatible with the protocol used in the 
post office system they want to access before they attempt to 
access the post office system. 

The IMAP4 protocol provides "online" manipulation of 
messages in the mail server and leaves the messages on the 
server. With IMAP4, users can remotely access the post 
office system, draft messages, view messages, and manage 
and manipulate post office files and folders locally within the 
server. The P0P3 protocol and other similar proprietary 
protocols, on the other hand, provide "offline" manipulation 
of messages. With P0P3, the remote client computer dovra- 
loads and deletes all the messages from the post office 
system. In P0P3, all message processing is local to the client 
computer. 

Although, presently, the P0P3 protocol is more widely 
used than IMAP4, IMAP4 is a more efficient protocol 
because IMAP4 minimizes data transfer time. With IMAP4, 
the remote client computer may review messages stored in 
the post office system and selectively download only desired 
messages. In this way, data transfer is limited to only those 
messages the user wants to download. On the other hand, 
with the P0P3 protocol, the remote client computer must 
download all messages, even those the user has no interest 
in downloading. Thus, P0P3 maximizes data transfer time 
and needlessly consumes client computer system resources. 

SUMMARY OF THE INVENTION 

To overcome the limitations in the prior art described 
above, the present invention discloses a system for accessing 
a folder of messages. A client computer estabhshes a first 
connection with a mail server including the folder of mes- 
sages over a network. The client computer communicates a 
command to the mail server to parse messages in the folder 
to obtain message headers. The message headers are then 
downloaded to the client computer. After downloading the 
message headers, the first connection between the cHent 
computer and the mail server is terminated. The cHent 
computer may then be used to select at least one displayed 
header. After message headers are selected, a second con- 
nection is established between the client computer and the 
mail server. The client computer oommunicates a command 
to the man server to retrieve a body for each message whose 
header was selected. The selected message bodies are then 
downloaded to the client computer. After downloading mes- 
sage bodies, the client computer communicates a command 
to the mail server to delete the selected messages from the 
folder in the mail server. The client computer then commu- 
nicates a command to the mail server to terminate the second 
connection between the client computer and the mail server. 

In further embodiments, to establish the first connection, 
the client computer conamunicates with a second server via 
the network iising a first protocol to download a first applet 
from the second server into the client computer. The first 
applet is executed in the client computer and performs the 
steps of: (1) establishing the first and second connections 
between the client computer and the mail server via the 
network using a second protocol; (2) displaying information 
in at least one of the message headers and message bodies 
downloaded from the mail server; and (3) generating and 
communicating the commands to the mail server. 

It is an object of the present invention to minimize data 
transfer time under a mail protocol, such as P0P3, that 
employs an "offline" mail protocol access scheme. 

It is a further object of the present invention to provide a 
system for accessing a post office system from a remote 
cUent computer using a downloaded applet, wherein the 
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remote clieat computer may display information on mes- that are personal computers, laptops, palmtops or 

sages in the post ofiEce system without downloading the workstations, and servers 36, 62 that are personal 

entire message. computers, workstations, minicomputers or mainframes. 

It is a further object of the present invention that the The network 32 may comprise networks such as LANs, 
downloaded applet include a protocol which is compatible 5 WANs, SNA networks, and the Internet, 

with a communication protocol used by the post ofiBce FIG. 3 illustrates farther details of the client computer 34, 

system, wherein the remote client computer operates under the server 36, the mail server 62, and the interaction ther- 

control of the applet to access the post office system in ebetween. In preferred embodiments, the client computer 34 

accordance with the protocol. includes a Hyper Text Mark-up Language (HTML) web 

It is a yet further object of the present invention to browser 38 (e.g., IBM's Web Explorer, Netscape's 

download more than one applet to configure the remote Navigator, Sun Microsystem's HotJava Browser, 

client computer to perform functions such as downloading Microsoft's Internet Explorer, etc.). In preferred 

files from the post ofBce system, displaying messages, and embodiments, the client computer 34 further includes a 

creating new messages which may be transmitted to the post Java™ platform which enables the client computer to 

office system. execute programs written in the Java"^" computer language. 

niese and various other features as well as advantages Java™ Platform may be installed in the client computer 

which characterize the present invention will be apparent ^4 or may be embedded m the web browser 38 software. A 

upon reading of the following detailed description and computer tha miplemenis the Java platfonn is referred to as 



review of the associated drawings. 



a Java virtual machine. The Java virtual machine hides the 
20 underlying operating system of the client computer 34 (e.g., 

BRIEF DESCRIPTION OF THE DRAWINGS Windows, Unix, AIX, Solaris, etc.) from Java based applets 

and applications. An applet is a generally small application 

Referring now to the drawings in which like reference program. The Java platform translates the Java based applets 

numbers represent corresponding parts throughout: and applications to bytecodcs which are understood by the 

FIG. 1 is a block diagram that illustrates the relationship ^5 underlying operating system of the chent computer 34. 

between a client computer and a post office system linked Xhe web browser 38 can generate a main mail page 40, a 

via a network, which is known in the prior art; compose page 42, and a view page 44. In preferred 

FIG, 2 is a block diagram that illustrates the relationship embodiments, the pages 40, 42, and 44 are HTML pages and 

between a client computer and a post office system hnked each page 40, 42, 44 includes a Java'''*^ applet. A mail applet 

via the Internet, which is known in the prior art; 46, a compose message applet 48, and a view applet 50 run 

FIG. 3 is a block diagram that illustrates the relationship in pages 40, 42, 44, respectively, to display information in 

between a client computer, a post office system, and an their respective pages 40, 42, 44. The mail applet 46 causes 

HTTP server in accordance with the present invention; the web browser 38 to display portions of the main mail page 

no. 4a is a flowchart that illustrates logic of how a cUent 35 t^' ^^""^ ^T'^^^ to various mail box folders and 

computer accesses a post office system in accordance with f^^^^^> ff^ ^^^'^^ ^^1^*^^' an outbox folder, a draft 

preferred embodiments of the present invention; ^^^^^^ /"^^er^ composition template, eta Tlie 

. „ t .1. , . ^. mail applet 46 further creates a thread to run a local Hyper 

FIG. 4b IS a flowchart that illustrates logic of how a user ^^^^ p^^^^^^j (^^^^ 3^^^^ 52. Ite compose 

at a chent computer selects a file m a post office system to 4^ ^^^^^ ^ 42 ^^^^^ 

view and download in accordance with preferred embodi- 40 ^^^^^^^ 3^ ^^^^^^ portions of the S^mpose page 42, 

ments of the present invention; ^^^^ provides a template to compose new messages, and 

FIG. 4c is a flowchart that illustrates logic of how a user reply to and forward received messages. The view applet 50, 

at a client computer composes messages for transmittal to a ^vhich runs in the view page 44, causes the web browser 38 

post office system in accordance with preferred embodi- to display portions of the view page 44 in which the user 

ments of the present invention; 45 ^^^^ ^.^^ content of messages. 

FIG. 5 is a flowchart that fllustrates logic of how a client preferred embodiments, the mail applet 46 is executed 

computer accesses a post office system utilizing an offline first to display the main mail page 40 including various mail 

mail protocol in accordance with preferred embodiments of box features. When the user selects to view or read a 

the present invention. message, the mail applet 46 opens the view page 44, which 

includes the view applet 50, Simflarly, when the user selects 
to compose, reply to or forward a message, the mail applet 
46 opens the compose page 42, which includes the compose 

In the following description, reference is made to the applet 48. In this way, in preferred embodiments, the applets 

accompanying drawings which form a part hereof, and 55 and web pages are only loaded when needed, 

which is shown, by way of illustration, several embodiments The client computer 34 further includes a post office cache 

of the present invention. It is understood that other embodi- 54 and a Java cache 55. The post office cache 54 stores 

ments may be utilized and structural changes may be made messages downloaded from the post office system 66 to the 

without departing from the scope of the present invention. client computer 34. The Java cache 55 stores the Java files, 

^0 applets, and classes which are needed to implement the mail 

System Description ^ppj^j compose applet 48, view applet 50, and afl the 

FIG. 3 schematically illustrates the environment of the functions thereof, 

preferred embodiment of the present invention, and more The server 36 includes an HTTP server 56 and Java 

particularly, illustrates a typical distributed computer system Archive (JAR) Ffles 60 which store Java applets in a 

30 using the Internet or other network 32 to connect a client 65 compressed format. The JAR files 60 are stored in a direc- 

computer 34 to a server 36 and a mail server 62. A typical tory in the server 3 6 which is relative to a directory including 

combination of resources may include cfients computers 34 the HTTP server 56. The HTTP server 56 receives a request 
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from the client computer to access the post office system 66- loading to the client computer 34 a web page with an 
The HTTP server 56 processes this request and transmits a embedded link to the JAR file. In preferred embodiments, 
web page to the client computer 34 with an embedded URL the client computer 34 extracts the applets from the down- 
link to a JAR file in the JAR files 60 directory. When the web loaded JAR file and stores the applets in the Java cache 55. 
browser 38 of the client computer 34 opens the web page 5 Upon downloading the JAR file and extracting the applets 
including the embedded link to a JAR file in the server 36, therein, control proceeds to block 98 which represents the 
the web browser 38 then transmits to the HTTP server 56 a web browser 38 opening the main mail page 40 and running 
request for the JAR file. The HTTP server 56 processes this ^^e mail applet 46 stored in the Java cache 55 in page 40. 
request and retrieves the requested JAR file to download to Control transfers to block 100, which represents the mail 
the client computer 34 via the network 32 for storage in the lO W^et 46 starting a new thread to run the local HTTP server 
Java cache 55. In preferred embodiments, the applets 46, 48, 52. In preferred embodiments, the local HTTP server 52 
50 are stored within a single JAR file downloaded to the ^o^^^ "^len in on port lUO. In such case, the URL location 
client computer 34. HTTP server 52 in the client computer 34 may 
™ , . c. • 1 J -1 be at http:\\localhost:1110. After invoking the main mail 
The present invention further includes a mail server 62 >ia j -i i * >iic * w c * ui i 

. ' c , 1..- ic page 40 and the mail applet 46, control transfers to block 102 

which may be a mainframe, mimcomputer, workstation or i5 . ^ , , • , • 

, •' , r-i which represents the mail applet 46 displaying a logm screen 

personal computer. The mail server 62 runs a mail protocol • *k ■ -i At\ r j & o 

64 (e.g., P0P3, IMAP4, SMTP, LDAP, etc.) and a post office '° . n^^"" \ . ui i . . ■ . 
system 66 (e.g., Lotus cc:Mail, Lotus Notes, Lotus Domino, ^^"f" 1^?, control proceeds to block 104 which 
Novell's Groupwise, etc.). In preferred embodiments, the represents the mail applet 46 opening a connection with the 
protocol which allows the client computer 34 to communi- 20 ^^^^ ^^ver 62 to provide the user logm mformaUon to the 
cate with the post office system 66 is maintained in the mail "^^'^ ^"l^' 62. Control transfers to block 106, which rep- 
applet 46, llius, the mail applet 46 runs a protocol compat- '^^^""^ "^"^l ^"^^^ ^P^rating under control of the 
ible with the mail protocol 64 in the mail server 62, e.g., ^^'} P^^^°^^^ ^5 authenticating the user logm information 
P0P3, IMAP4, etc. In this preferred embodiment, the mail [^^^^^ ii^ormatioQ is not authenUcated, coiitrol 
applet 46 provides the only socket link to the post office 25 transfers to block 108; otherwise control transfers to block 
system 66 for the cHent computer 34. ^^^^^ V*^ represents the tnail applet 46, upon receiving 
\^ , . . . . , , indication of authentication failure from the mail server 62, 

Thus, the present inveiition may be implemented as a displaying a login incorrect message in the main mail page 

method, apparatus or article of manufacture using standard ^^^^^ represents the mail applet 46, upon receiving 

programming and/or engineermg techniques to produce indication of authentication, opening a comiection with the 

software, firmware hardware, or any coni^ ^^^^ ^ ^^^^ ^^^^^^^ ^ 

ITieterm article of manufacture as used herein is mtended discussed, the mail applet 46 includes a mail protocol 

to encompass any device earner, or media that provides ^ible with the mail protocol 64 employed in the mail 

access to instructions and/or data useful m performmg the ^^^^^ g^. Control transfers to block 112 which represents 

same or similar functionality. ^^^^^^^ 3g displaying in the main mail page 40 

Those skilled in the art will recognize that the exemplary graphical representations of common e-mail program 

environment illustrated in FIG. 1 is not intended to limit the features, e.g., an inbox, outbox, trash, message composition 

present invention. Indeed, those skilled in the art will options, etc. 

recognize that other alternative hardware environments may Control then transfers to block 114, which represents the 

be used without departing from the scope of the present ^.1^^^^^ computer 34 waiting for the user to select a view 

invention. For instance, in alternative embodiments, the ^^^^^^ ^^^^ j^^in mail page 40. Upon receiving such a 

HTTP server 56, JAR files 60, mail protocol 64, post office request, control transfers to block 116, which represents the 

system 66 or any combination thereof may be mstafied on a ^^^^ ^ppi^t 46 fiinctioaing as a file viewer to allow the user 

single computer server or over several servers distributed traverse and view information on files in the post office 

over a network. system 66. The user may view information on the files in the 

Accessing the Post Office System P"^' office system without downloading such files. In pre- 

lerred embodiments, a user logged mto the post omce 

Flowcharts which illustrate preferred embodiments of the system 66 is restricted to only viewing files in such user's 

logic for accessing a post office system in accordance with mailbox and not files in other users' mailboxes, 

the present invention are shown in FIGS. 4a, 4b, and 4c. 50 FIG. 4b illustrates a preferred embodiment of logic for 

Those skilled in the art will recognize that this logic is allowing the user to select a file in the post office system 66 

provided for illustrative purposes only and that different to view and download to the client computer 34 in accor- 

logic may be used to accomplish the same results. dance with the present invention. Block 130 represents the 

FIG. 4a is a flowchart showing logic for how the client client computer 34 waiting for the user to select a file in the 
computer 34 initially accesses the post office system 66 in 55 post office system 66. In preferred embodiments, the user 
accordance with the present invention. At block 90, the would first view information on the files in the user mailbox 
system waits for a user to attempt to access the post office in the post office system 66 in the manner discussed with 
system 66 using the web browser 38. Control transfers to respect to FIG. 4a. The user may select a viewed file with an 
block 92 which represents the web browser 38 transferring input device attached to the client computer 34. For instance, 
a request to the HTTP server 56 via the network 32 to access 60 if a mouse pointer is used as the input device, then the user 
the post office system 66. Control then transfers to block 94 may select a file in the post office system 66 by double- 
which represents the HTTP server 56 processing the request clicking the viewed file with the mouse pointer. Upon 
and retrieving a JAR file inclaiding the three applets 46, 48, selecting a file at block 130, control proceeds to block 132 
50 and related programs and files. The HTTP server 56 which represents the mail applet 46 using the Java™ show- 
transmits the retrieved JAR file to the client computer 34 for 65 Document command to cause the web browser 38 to open 
storage in the Java cache 55. As discussed, in preferred the view page 44 including the selected file. The view page 
embodiments, the JAR file is downloaded by first down- 44 may reference the selected file using a Uniform Resource 
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Locator (URL) name in the local HTTP server 56. For (2) <html><body> 

instance, if the user selects a message file in the post office ^ parts* 2<p> 

system 66, the selected message may have the foUowing href="http7/localhost:1110/PART+863822044.00af 0" 

URL in the local HTTP server 56: larget=''ContentArea">0: nuU: text/plain 

http:\\localhost:1110/MESSAGExxxxx.xxxx 5 , ^ 

Control transfers to block 136 which represents the web 

browser 38 requesting the user selected file from the local <^ hrefo«http:/Aocalhost:1110/PART+863822044.00a.l" 

HTTP server 56. To retrieve the user selected file included ^^^S^^^ 'ContentArea">l : nuU: text/html 

in the view page 44, the web browser 38 may issue a Java </a><p> 

GET command, such as the following: GET MES- </body></html> 

SAGExxxxx.xxxx to retrieve the user selected message. The PART is the actual data for each part of the mime 
Control transfers to block 138, which represents the local message (or attachment). The BODY is the main text of the 
HTTP server 56 passing the request for the selected file to message, and may be plain text or an HTML file. CON- 
the mail applet 46. Control then transfers to block 140 which TROLS is an applet that generates a control panel of icons 
represents the mail applet 46 determining whether the 15 representing various compose operations discussed below, 
selected file is already located in the post office cache 54. If The user can select one of the operations fi-om the control 
so, control transfers to block 142; otherwise control transfers panel to reply or forward the message displayed in the other 
to block 144. Block 142 represents the mail applet 46 frames of the view page 44. Selection of a compose opera- 
obtaining the requested file from the post office cache 54. tion spawns the compose page 42 in the manner discussed 
Block 144 represents the mail applet 46 accessing the post below. 

office system 66 to obtain the selected file. Block 146 Thus, the view page 44 generated by the HTML template 

represents the mail server 62 downloading the selected file (1) in the above example displays a header for the message 

from the post office system 66 to the post office cache 54 in in one frame, the body of the message in a second frame, 

the client computer 34. In this way, files are only down- information on any additional attachments to the message in 

loaded from the post office system 66 when unavailable in ^5 a third frame, and icons representing various compose 

the cache 54, thereby minimizing downloading operations operations, which provide a link to the compose page 42, in 

and time. the fourth frame. 

From blocks 142 and 146, control transfers to block 148 From block 148, control transfers to block 150 which 

which represents the mail applet 46 assembling an HTML represents the mail applet 46 passing the assembled HTML 

template including tags to the selected file already stored in template for the view page 44 to the local HTTP server 52. 

the post office cache 54 or downloaded from the post office Control transfers to block 152 which represents the local 

system 66. An example of an HTML template (1) for the HTTP server 52 passing the assembled template to the web 

view page 44 that the mail applet 46 would assemble is browser 38 to display the view page 44 and selected file, 

provided below. In this example (1), the user selected which in the above example is the contents of the selected 

message is identified as 863822044.000. ^5 message. 

(1) <html> FIG. 4c illustrates a preferred embodiment of the logic for 

<frameset rows="20% 80%"> performing compose operations, such as composing new 

<frameset cols-"60%,io%"> ""^^^es, replying to messages, and forwarding messages 

The compose page 42 can be invoked from the mam mail 

<framename-"HeaderArea"src-"http://localhost:1110/ 40 page 40 or from the frame in the view page 44 running the 

HEADER+86382 2044.000"> CONTROLS applet. Block 160 represents the client com- 

<frame name=" AttachmentArea" src="http:// puter 34 waiting for the user to invoke a compose operation 

localhost:1110/ArTACHMENTS+863822044.000"> from the main mail page 40 or view page 44. In preferred 

</frameset> embodiments, the user may perform the following compose 

<frame name^^ContentArea" src="http://localhost:1110/ operations: creating a new message; fonvarding a message; 

BODY+863822044.000"> replying to the sender of the message; replying to all 

P ur^ , yy uu**- in iu . 11 ir./ addressees in a message; replying to the sender with the 

<frame name= ContfolArea src= http://localhost:1110/ . , , , , . . „ j. -.1... 

CONTOOLS+863 822044.000"> '"^^^S^ '^^^f'f] "^^^^^^ '° ""'^ * 

sage included; deleting the message; and prmting the mes- 

</irames6t> 50 g^ge. Many of these operations, such as forwarding and 

</html> replying, may only be invoked from within the view page 44 

The selected message includes four separate component while a selected message is displayed. 

files, HEADER, ATTACHMENTS, BODY, and CON- Control transfers to block 162 which represents the view 

TROLS. These four separate components of the selected applet 50 or mail applet 46 transferring a command corrc- 

message (863822044.000) were downloaded to the post S5 spending to the selected compose operation to the local 

office cache 54 at blodb 144 and 146 and are identified by HTTP server 52. Below is list of HTTP commands used to 

a URL in the local HTTP server 56. The HTML template (1) initiate compose operations: 

in the above example creates four frames within the view CREATE* Creates a message 

page 44. Each frame in the view page 44 tags the URL for FORWARD: Forwards a message. 

one of the above four component files to display m that 60 „T-r.T-t7Tr^c-i-»TTM-i. ^ 

frame. The "HEADER" is a plain text document that REPLYTOSENDER: Compose new message to reply to 

includes message information, such as the author, recipients sen er o message. 

and subject of the message. "ATTACHMENTS" is an REPLYTOALL: Replies to all addressees in a message. 

HTML document that contains a list of URL links to the REPLYTOSENDERWITHMESSAGE: replies to sender 

actual attachments to the message. An example (2) of an 65 with message included. 

ATTACHMENT HTML page displayed in one of the frames REPLYTOALLWITHMESSAGE: Replies to aU address- 

of the view page 44 is provided below: ees with the message. 
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DELETE: Deletes a message. 
PRINT: Prints a message. 

The mail applet 46 or view applet 50 would send one of 
the above commands corresponding to the user selected 
operation. From block 162, control transfers to block 164 
which represents the local HTTP server 52 transferring the 
command to the mail applet 46. Control transfers to block 
166 which represents the mail applet 46 assembling a 
compose page 42 including the compose applet 48 to 
perform the user selected compose operation. If the user had 
invoked the compose operation while viewing a message in 
the view page 44, the mail applet 46 may include the viewed 
message or information thereon in the assembled compose 
page 42. In such instance, the compose operation relates to 
the message the user was previously viewing. After assem- 
bling the compose page 42, control transfers to block 168 
which represents the mail applet 46 sending the compose 
page 42 to the local HTTP server 52. Control transfers to 
block 170, which represents the web browser 38 displaying 
the assembled compose page 42 and running the compose 
applet 48 therein. 

Control then transfers to block 172 which represents the 
user performing the selected compose operation in the 
compose page and selecting to send a composed message to 
the post ofiBce system 66. If the user had selected compose 
operations such as deleting or printing a message, then the 
send option may not be available. However, if the send 
option is available and was selected, control transfers to 
block 174 which represents the compose applet 48 transfer- 
ring the sent message to the local HTTP server 52. Control 
then transfers to block 176 which represents the local HTTP 
server 52 transferring the sent message to the mail applet 46, 
which, at block 178, transfers the sent message to the post 
office system 66 via the network 32. 

In further embodiments, multiple compose pages 42 and 
view pages 44 may be opened in the web browser 38 at the 
same time. To implement multiple pages, the compose 48 
and view 50 applets would include an argument for a code 
which identifies the current message opened in the compose 
42 or view 44 page running the compose 48 or view 50 
applet, respectively. This way, the compose 48 or view 50 
applet running in a page will recognize which message it is 
operating on. 

Accessing the Post Office System Using the P0P3 Pro- 
tocol 

Preferred embodiments of the present invention allow the 
user to selectively download mail messages from the post 
office system 66 using the P0P3 protocol or a similar 
"ofQine" mail protocol scheme. As discussed, in prior art 
post office systems utilizing the P0P3 or similarly offline 
type protocols, when users access their mail box within the 
post office system 66, all the messages in the inbox are 
downloaded and subsequently deleted from the post office 
system 66. The preferred embodiment utilizes the P0P3 
protocol to allow the iiser to selectively download messages, 
thereby minimizing data transfer time to only those mes- 
sages and files the user is interested in downloading. 

FIG. 5 is a flowchart that illustrates a preferred embodi- 
ment of logic implemented in the client computer 34 to 
retrieve messages from a folder in the post office system 66, 
such as an inbox folder, outbox message folder, draft mes- 
sage folder, bulletin board, etc., using the P0P3 protocol or 
a similar offline protocol. The flowchart begins at block 180 
which represents the client computer 34 waiting for the mail 
applet 46 to establish a connection with the mail server 62. 
Control transfers to block 182 which represents the mail 
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applet 46 issuing a POP3 or similar protocol command to the 
mail server 62 to look-up messages added to a folder, such 
as the inbox, and obtain the headers for such new messages 
added to the folder. The P0P3 command would parse the 

5 messages in the selected folder to obtain the header. For 
instance, the P0P3 protocol includes the TOP command to 
retrieve a portion of a specified message from the post office 
system. The TOP command receives two arguments, the 
message number and the nimaber of lines in the message 
body beyond the header. 

Control then transfers to block 184 which represents the 
mail server 62 transmitting the parsed message headers from 
the post office system 66 to the mail applet 46. Control 
transfers to block 186 which represents the mail applet 46 
issuing a command to terminate the connection with the mail 
server 62. In P0P3 and other similar offline protocols, after 
downloading message information, the coimection is termi- 
nated. The downloaded messages are stored in the post office 
cache 54 in the client computer 34. Control proceeds to 
block 188 which represents the mail applet 46 displaying the 

20 received message headers in the main mail page 40. In 
further embodiments, the message headers may be displayed 
in the view page 44. Control then transfers to block 190 
which represents the client computer 34 waiting for the user 
to select one of the displayed message headers. 

25 . Upon user selection of at least one message header, 
control transfers to block 192 which represents the user 
selections communicated to the mail applet 46, Control then 
proceeds to block 194 which represents the mail applet 46 
establishing communication with the mail server 62 and 

30 requesting the message bodies for the user selected message 
headers. The mail applet 46 would issue a command such as 
the P0P3 RETR command to retrieve the body of the 
selected messages. Block 196 represents the mail server 62 
downloading the selected messages. After receiving the 

35 selected message bodies, control transfers to block 198 
which represents the mail applet 46 communicating a com- 
mand to mark the retrieved messages as deleted, which in 
P0P3 is the DELE command. The deleted messages are 
deleted from the post office system 66 when the connection 

40 between the client computer 34 and mail server 62 is 
terminated. Control transfers to block 200 which represents 
the mail applet 46 terminating the connection with the mail 
server 62 and the mail server 62 deleting the messages from 
the post office system 66 marked as deleted. Control then 

45 transfers to block 202 which represents the mail applet 46 
transmitting the received message bodies to the view applet 
50 which displays the message bodies in the view page 44 
for the user to read. 

In this way, preferred embodiments utilize the P0P3 

50 protocol in a manner that minimizes data transfer time. Mail 
box manipulation remains local to the client computer 34 as 
with the P0P3 protocol, but data transfer time is minimized 
by selectively downloading only selected message bodies. 
The P0P3 commands are described in the Internet Engi- 

55 nee ring Task Force (IETF), Request for Comments No. 
1939, by John G. Myers and Marshall T Rose, incorporated 
herein by reference in its entirety. 

Conclusion 

60 This concludes the description of the preferred embodi- 
ments of the invention. The following describes some alter- 
native embodiments for accomplishing the present inven- 
tion. 

Preferred embodiments were described with respect to the 
65 P0P3 mail protocol. However, similar proprietary "offline" 
mail protocols would also benefit from the present inven- 
tion. 
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In alternative embodimenls, the applets may be down- 
loaded from a server other than an HTTP server and may be 
in a format different from the JAR formal described above. 

In still further embodiments, the functions described wiib 
respect to the mail applet, the compose applet, and the view ^ 
applet may be performed by one or more applets in a manner 
different than the manner described above. Moreover, the 
local HTTP server may be spawned in the web browser 
outside of the page including the main applet. 

In addition, those skilled in the art will appreciate that the 
present invention is not limited by a specific programming 
language. The applets may be implemented in other pro- 
gramming languages, such as C, C++, PERL, Cobol, 
Smalhalk, etc. 

Still further, the compose, view, and main mail page may 
be implemented in formats other than the HTML formats 
described above and the applets may communicate by a 
means other than the local HTTP server design described 
above. 

Although the present invention is described with respect 
to a post ofi&ce system, those skilled in the art will appreciate 
that the present invention may be used to access a database 
system, other than a post ofi&ce system, from a remote 
computer over a network. In such case, the user may utilize 25 
the applets and preferred embodiments discussed with 
respect to the post office system to access and view infor- 
mation on files in the database system over the network, 
download viewed files, view the contents of downloaded 
files, and compose files at the remote location for transmittal 3Q 
to the database system. 

In summary, the present invention discloses a system for 
accessing a n inbox of messages. A client computer estab- 
lishes a first connection with a mail server including the 
inbox of messages over a network. The client computer 35 
communicates a command to the mail server to parse 
messages in the inbox to obtain message headers. The 
message headers are then downloaded to the client com- 
puter. After downloading the message headers, the first 
connection between the client computer and the mail server 40 
is terminated. The client computer may then be used to select 
at least one displayed header. After message headers are 
selected, a second connection is established between the 
client computer and the mail server. The client computer 
communicates a command to the mail server to retrieve a 45 
body for each message whose header was selected. The 
selected message bodies are then downloaded to the client 
computer. After downloading message bodies, the client 
computer communicates a command to the mail server to 
delete the selected messages from the inbox in the mail 50 
server. The client computer then communicates a command 
to the mail server to terminate the second connection 
between the client computer and the mail server. 

The foregoing description of the preferred embodiments 
of the invention has been presented for the purposes of ss 
illustration and description. It is not intended to be exhaus- 
tive or to Umit the invention to the precise form disclosed. 
Many modifications and variations are possible in light of 
the above teaching. It is intended that the scope of the 
invention be limited not by this detailed description, but 60 
rather by the claims appended hereto. The above 
specification, examples and data provide a complete descrip- 
tion of the manufacture and use of the composition of the 
invention. Since many embodiments of the invention can be 
made without departing from the spirit and scope of the 65 
invention, the invention resides in the claims hereinafter 
appended. 
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What is claimed is: 

1. A method for accessing a folder of messages, compris- 
ing the steps of: 

(a) establishing a first connection between a client com- 
puter and a mail server including the folder of messages 
over a first network; 

(b) communicating a command from the client computer 
to the mail server to parse messages in the folder to 
obtain a message header; 

(c) downloading the message headers to the client com- 
puter; 

(d) terminating the first connection between the client 
computer and the mail server after downloading the 
message headers; 

(e) selecting with the client computer a displayed header; 

(f) establishing a second connection between the client 
computer and the mail server; 

(g) communicating a command from the client computer 
to the mail server to retrieve a body for each message 
whose header was selected; 

(h) downloading the selected message bodies to the client 
computer; 

(i) communicating a command from the client computer 
to the mail server to delete the selected messages from 
the folder in the mail server; and 

(j) communicating a command from the client computer 
to the mail server to terminate the second connection 
between the client computer and the mail server. 

2. The method of claim 1, wherein the step of establishing 
the first connection between the client computer and the mail 
server further comprises the steps of: 

communicating between the client computer and a second 
server via the network using a first protocol; 

downloading a first applet from the second server into the 
client computer via the network using the first protocol; 
and 

executing the downloaded first applet in the client 
computer, wherein the executed first applet performs 
the steps of: 

(1) establishing the first and second connections 
between the client computer and the mail server via 
the network using a second protocol, 

(2) displaying information in at least one of the mes- 
sage headers and message bodies downloaded from 
the mail server; and 

(3) generating and communicating the commands to the 
mail server. 

3. The method of claim 2, wherein the network is the 
Internet. 

4. The method of claim 2, further including the step of 
downloading a second applet from the second server and 
executing the second applet in the client computer, and 
wherein the step of displaying information in at least one of 
the message headers and message bodies further comprises 
the steps of: 

communicating information in at least one of the message 
headers and message bodies from the first applet to the 
second applet; and 

generating with the second applet a page displaying the 
information communicated from the first applet. 

5. The method of claim 4, further including the steps of: 
downloading a third applet from the second server using 

the first protocol; 
executing the third applet in the client computer; 
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generating with the third applet a second page displayed 

on the client computer; 
creating a message by entering information with the client 

computer into the second page; and 
communicating the created message to the mail server 

using the second protocol. 

6. The method of claim 5, wherein the step of transferring 
the created message to the mail server further comprises the 
steps of transferring the created message to the first applet 
and transferring the created message from the first applet to 
the mail server via the network xising the second protocol. 

7. The method of claim 2, further comprising the steps of: 
downloading a second applet from the second server 

using the first protocol; 
executing the second applet in the client computer; 
generating with the second applet a page displayed on the 

client computer; 
creating a message by entering information with the client 

computer into the second page; and 
communicating the created message to the mail server. 

8. The method of claim 2, wherein the mail server and 
second server are located within a single computer system. 

9. An apparatus for accessing a folder of messages, 
comprising: 

(a) means for establishing a first connection between a 
client computer and a mail server including the folder 
of messages over a network; 

(b) means for communicating a command from the client 
computer to the mail server to parse messages in the 
folder to obtain a message header; 

(c) means for downloading the message headers to the 
client computer; 

(d) means for terminating the first connection between the 
client computer and the mail server after downloading 
the message headers; 

(e) means, performed by the client computer, for selecting 
a displayed header; 

(f) means for establishing a second connection between 
the client computer and the mail server; 

(g) means for communicating a command from the client 
computer to the mail server to retrieve a body for each 
message whose header was selected; 

(h) means for downloading the selected message bodies to 
the client computer; 

(i) means for communicating a command from the client 
computer to the mail server to delete the selected 
messages from the folder in the mail server; and 

(j) means for communicating a command from the client 
computer to the mail server to terminate the second 
connection between the client computer and the mail 
server. 

10. The apparatus of claim 9, wherein the means for 
establishing the first connection between the client computer 
and the mail server further comprises: 

means for commimicating between the client computer 
and a second server via the network using a first 
protocol; 

means for downloading a first applet from the second 
server into the client computer via the network using 
the first protocol; and 

means, performed by the first applet executed in the client 
computer, for: 

(1) establishing the first and second connections 
between the client computer and the mail server via 
the network using a second protocol, 
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(2) displaying information in at least one of the mes- 
sage headers and message bodies downloaded from 
the mail server; and 

(3) generating and communicating the commands to the 
5 mail server. 

11. The apparatus of claim 10, wherein the network is the 
Internet. 

12. Tlie apparatus of claim 10, further including means for 
downloading a second applet from the second server and 
executing the second applet in the client computer, and 
wherein the means for displaying information in at least one 
of the message headers and message bodies further com- 
prises: 

means for communicating information in at least one of 
J 5 the message headers and message bodies from the first 

applet to the second applet; and 
means, performed by the second applet, for generating a 

page displaying information communicated from the 

first applet. 

20 13. The apparatus of claim 12, farther including: 

means for downloading a third applet from the second 
server and executing the third applet in the client 
computer; 

means, performed by the third applet, for generating a 
25 second page displayed on the client computer; 

means, performed by the client computer, for creating a 

message by entering information into the second page; 

and 

means for communicating the created message to the mail 
30 server. 

14. The apparatus of claim 13, wherein the means for 
transferring the created file to the mail server further com- 
prises the steps of transferring the created file to the first 
applet and transferring the created file from the first applet 

^5 to the mail server via the second network using the second 
protocol. 

15. The apparatus of claim 10, further comprising: 
means for downloading a second applet from the second 

server and executing the second applet in the client 
computer; 

means, performed by the second applet, for generating a 
page displayed on the client computer; 

means, performed by the client computer, for creating a 
message by entering information with the client com- 
puter into the second page; and 

means, performed by the first applet, for communicating 
the created message to the mail server. 

16. The apparatus of claim 10, wherein the mail server 
and second server are located within a single computer 
system. 

17. An article of manufacture for use in programming a 
client computer, the article of manufacture comprising a 
computer readable storage medium having a computer pro- 
gram embodied therein that causes the client computer to 
perform the steps of: 

(a) estabhshing a first connection between the client 
computer and a mail server including the folder of 
messages over a network; 
go (b) communicating a command from the client computer 
to the mail server to parse messages in the folder to 
obtain a message header; 
(c) downloading the message headers to the client com- 
puter; 

65 (d) terminating the first connection between the client 
computer and the mail server after downloading the 
message headers; 
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(e) selecting with the client computer a displayed header; 
(Q establishing a second cooneclion between the client 
computer and the mail server; 

(g) communicating a command from the client computer 
to the mail server to retrieve a body for each message 
whose header was selected; 

(h) downloading the selected message bodies to the client 
computer; 

(i) communicating a command from the client computer 
to the mail server to delete the selected messages from 
the folder in the mail server; and 

(j) communicating a command from the client computer 
to the mail server to terminate the second connection 
between the client computer and the mail server. 

18. The article of manufacture of 17, wherein the step of 
establishing the first connection between the client computer 
and the mail server further comprises the steps of: 

communicating between the client computer and a second 
server via the network using a first protocol; 

downloading a first applet from the second server into the 
client computer via the network using the first protocol; 
and 

executing the downloaded first applet in the client 
computer, wherein the executed first applet performs 
the steps of: 

(1) establishing the first and second connections 
between the client computer and the mail server via 
a second network using a second protocol; 

(2) displaying information in at least one of the mes- 
sage headers and message bodies downloaded from 
the mail server; and 

(3) generating and communicating the commands to the 
mail server. 

19. The article of manufacture of claim 18, wherein the 
network is the Internet. 

20. The article of manufacture of claim 18, further includ- 
ing the step of downloading a second applet from the second 
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server and executing the second applet in the client 
computer, and wherein the step of displaying information in 
at least one of the message headers and message bodies 
further comprises the steps of: 

communicating information in at least one of the message 
headers and message bodies from the first applet to the 
second applet; and 
generating with the second applet a page displaying the 
50 information communicated from the first applet. 

21. The article of manufacture of claim 20, further includ- 
ing the steps of: 

downloading a third applet from the second server; 
executing the third applet in the client computer; 
generating with the third applet a second page displayed 

on the client computer; 
creating a message by entering information with the client 

computer into the second page; and 
communicating the created message to the mail server. 

22. The article of manufacture of claim 21, wherein the 
step of transferring the created file to the mail server further 
comprises the steps of transferring the created file to the first 
applet and transferring the created file from the first applet 
to the mail server via the second network using the second 
protocol. 

23. The article of manufacture of claim 20, further com- 
prising the steps of: 

30 downloading a second applet from the second server; 
executing the second applet in the client computer; 
generating with the second applet a page displayed on the 

client computer; 
creating a message by entering information with the client 

computer into the second page; and 
communicating the created message to the mail server. 

M * * * * 
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[57] ABSTRACT 

The invention provides a cryptographic system and method 
with a key escrow feature that uses a method for verifiably 
splitting users' private encryption keys into components and 
for sending those components to trusted agents chosen by 
the particular users, and provides a system that uses modem 
public key certificate management, enforced by a chip 
device that also self -certifies. In a preferred embodiment of 
this invention, the chip encrypts or decrypts only if certain 
conditions are met, namely, (1) if a valid "sender certificate" 
and a valid "recipient certificate" are input, where "valid" 
means that the particular user's private decryption key is 
provably escrowed with a specified' number of escrow agents 
and that the master escrow center is registered and certified 
by the chip manufacturer, and (2) if a valid Message Control 
Header is generated by the sender and validated by the 
recipient, thereby giving authorized investigators sufficient 
information with which to request and obtain the escrowed 
keys. A preferred embodiment provides for encryption of 
stream-oriented data. 
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FIG, 14 
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FIG. 18 
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VERSION No. 



(MESSAGE KEY) KE+reclp 



SENDER ESCROW CENTER NAME (eel) 



SENDER ESCROW CENTER COUNTRY CODE 



RECIPIENT ESCROW CENTER NAME ( ec2 ) 



RECIPIENT ESCROW CENTER COUNTRY CODE 



(SENDER ESCROW CERT. No. ) KE+ecl 



(MESSAGE KEY) KE+sender (TO HIMSELF) 



( RECIP . ESCROW CERT . No . ) KE+ec2 



TIMESTAMP (OPTIONAL) 



SENDER DEVICE SIGNATURE 



181 



181 

■181 
•181 



08/28/2003, EAST Version: 1.04.0000 



U.S. Patent 



Dec. 15, 1998 



Sheet 13 of 20 



5,850,451 



UJ 

> 



UJ 

□ 

UJ 



m 
in 



LO in in 



a 
u 

UJ 





















LU 


















O) 






=] 








u 


u 




LU 


Oi 


e 


(U 


(U 


< 






+ 


1 


1 


Z 


U 


□ 


(/I 




LU 


ID 


< 












a. 


1 








(/) 




LU 








1- 


:^ 








>- 


Q. 










LL 


>• 


LU 




® 


ERI 


u 

LU 


a 








> 


a 










• 


• 


« 



VERIFY 
I 1 



(O 

in 











o 








z 






ec 




L 




1 


LU 


QJ 


> 




to 








LU 


□ 








+ 




U 


LU 






n 








> 






LU 








□ 









UJ 












< 
















1 


h- 


U 




z 


01 




u 


+ 










□ 












U 












LU 







OD 

in 



in 



LU CI 



1 1 



UJ 



LU 
U 

> 
LU 

a 

Q 
LU 

CO 
Z] 









L 
















































A 












> 


L 


L 


cn 


o 


> 




(U 


0) 










in 




e 




XI 


+ 






+ 


+ 


1 












t/) 




UJ 


LU 








V 







® 



LU 
I I- 
Z< 

Luci: 

LDLU 



® 



ID 
Q. 
I- 

□ 



.in 



I- 

Q- 



® 



® 



Z 
< 



CM 

in 














o 






z 












LU 






to 


L 


L 






OJ 


LU 


m 


m 


U 


□ 




M 


1 




> 


LU 


m 


LU 






O 



>- 
u. 

- -I °^ 

1 UJ 

, > 



No. 




O) 






e 






1 


LU 


> 














LU 


H- 




U 






M 






> 






LU 






a 







LU 












< 




O 


z 




in 






1 


1- 






z 


U 




u 


OJ 

+ 






LU 




□ 












u 






(/) 






LU 







in 
in 



< 
I- 

□ 



08/28/2003, EAST Version: 1.04.0000 



U.S. Patent Dec. is, 1998 Sheet 14 of 20 5,850,451 



tDQl>LULU 



o 



LU 

< 
U 
M 

LL 
LU 

u 



LL 
-OLU 

Lut/i ai 

ULUU 



2 







U 






LU 






1 


□ H 


O 










U LU 








LU 




LU < 







CO 











2: 




u 


u u 






- 


+ + 


a 


(/^LU 






u 






LU 















> 


LU 






w 




-o 






1 






u 


> 






0) 






•D 


Oi 






E 


E E 




O 


o a 


QJ 


c 


c c 


e 






o 




rsim 


c 


a 


0 o 




QJ 


(U (U 


L 










in 






D 







in 

(O 



(O 




ZLU 
Luxmom 

LDLD XD L 

< - 
LUQ^(M< CM 

>>^a - 

LULU X Z 





> 




OJ 




T) 


m 


1 






c - <u 




O L ^ 




c ^ oj m 




% in L 








(u >+ m 




in oj uj X 









CO 

o 

^ <U CM 

% m L 

>+ CM 
01 LU X 



3T) V w 



to 









> 








01 








"D 








1 


OJ 




o 




e 




OJ 




o 


L 






c 










% m 


L 




L 








OJ 








ut 


(UUJ 


X 











m 

CO 



> 

LU - 

LDpn 

< X 

- 

a oi 

U O 

LU in 





m 


L 


o 


01 a 


OJ 


in 01 


1 










LU > 




V OJ 








OJ - 




EH 




a L 




c ^ 





m 

ID 



CM% 
> 

I- OJ 

UJ ^ 
L3CM 
< X 



□ OJ 
U O 

LU in 





CM 




O 


OJ O 


QJ 


in OJ 


1 






+ =»t 




LU > 




U OJ 








OJ - 




ECM 




O L 









U3 



m 

(O 



> 

I- 01 

2: XI 
LU - 
ID — 
< X 

O OJ 

u o 

t/14> 

LU in 









L 




o 


OJ 


0 


QJ 


m 


OJ 










+ 






LU 


> 






OJ 






■0 




OJ 






E 








L 




C 









m 




L 








CM 




L 


U 










LLU 


a 






X 


u 


LLt/) 




M 


LU 






UJ 




> 



OJ 
E 

a L 
c OJ > 
m OJ 

L 3T3 
0J + + 
lALUl/) 
3 W 



U3 



Q^UJ 
UH 
C/) < 
LUU 
M 
LUO. 
H M 

LUCk: 

C^LU 
UU 



LU 



UJ 



08/28/2003, EAST Version: 1.04.0000 



U.S. Patent 



Dec. 15, 1998 



Sheet 15 of 20 



5,850,451 





















L 




> 






a 


OJ 










— 


T) 




"D 






u 


C 




1 






Ci 






LL 






VI 






< 






+ 






LU 




Lii 


LU 










O) 


O) 
Ul 










£ 


E 






r\P" 





































A 




/ 



J 1 z 



U / 





A 




Q 










LU 














L 






C/1 










ZI 










UJ 


evl 




^'SWQ 




h-U 

M 


A 




(/) > 


T) 


> 




. LU 


1 

CO 


(U 






c^a 

LU 








a 














V 






LU 




V 






(/) 












1 



O L 
> O) 

^ £ 

Mill 

□ ID 
IH 
h-U 
Z)< 
<LL 

UJZ 

a< • 

» UJ 
ZLUX 
UJOQI- 

I- □ 
HZ 

xa 
(/)ua 



UJ 

a 



A 



m 






















□ 










O LU 






CM 


Ck^LU 


L 




U 










U 


U H- 
t/1 < 


Qi 

•n 




Oi 

1 




u < 
t/0 u 


a 


CM 
> 

+ 

I/) 


(U 
1 


NDER E 
RTIFIC 


KE+sent 


> 

01 
T3 
+ 






CIP. E 
ERTIFI 


KE+rec 




LULU 








LULJ 






C/)U 



















Ul 

QJ < 
H- U 

> U. 

h- 
CMQ^ 
UUJ 
LUU 



LU 
LL 

I m 
f 



in 



Ilu 

LX. 
i-i 
Of 
LU 
> 



LU 
> 

LU 
> 
□ 



I 
U 
21 



LU 

l:] 
< 

to 

LU 

2: 

Q 
LU 

CL 
> 

u 
z 

LU 

D 
Z 
LU 



CD 



08/28/2003, EAST Version: 1.04.0000 



U.S. Patent 



Dec. 15, 1998 



Sheet 16 of 20 



5,850,451 











□ LU 






ru 


Q^\- 






u 


U< 

(/)U 


a 


(\J 


oi 

1 


LU M 
LL 
• i-i 


ec 


> 




ULU 


LU 


+ 




LUU 















LU 
ID 
< 

{/) 

LU 



















L 




> 




CL 


oi 








U 


c 




1 




Oi 


Qi 








L 


V) 








+ 


H- 








LU 


LU 




























O) 


O) 








Ul 


in 








E 


E 










V 

















-1 ^ 

' LU 

I > 
I 











□ 








111 


t 




u 


Uh- 


KE+sender 




01 


t/i< 


KS+devl 


1 


NDER E 
RTIFIC 




LU lU 















LU 



t___ 



lU 



LU 

< 
U 

M 
LL 



LU 
U 



(M 
U 



O 

I 



LU 
M 
> 

LU 
> 
□ 



u 



LU 
ID 
< 
</) 
1/3 
LU 
Z 

a 

LU 
h- 
CL 
> 

u 
2: 

LU 

LU 
> 

LU 
U 
LU 

Cki 



S2 



LU 



LU 
> 



LU 
> 



08/28/2003, EAST Version: 1.04.0000 



U.S. Patent 



Dec. 15, 1998 



Sheet 17 of 20 



5,850,451 




2 IJJ * » JO 

M u i/omat: 

• M H UJ ^ IK 2 

^l-UJ>Q£Z UlU 
m M 111 liJ < LL 13 

□ z3aLJzaiu< 



® 



(O 

o 



D 
CD 



M < X < 0^ LU Z 

GD J CD u • - a u 
^ - • a -D 
1/1 — • c\j m m 



f— N 

OJ 


o 

X 
□ 
CD 


>>> 








LU UJ LU 
w \/ \/ 

J£> 

i-L3Ck:a^ 

a MLU u 

LU I/) z: ui 




@ 

m 


1 

-J 




0^ 


u uia 




X 


< 




UJ 




:^ 




> 




a 


> - > 


u 






LU 


□ 


LD M m M 


a 




UJ 


-J 


u 


LLQ^ ZlQ^ 


-J 


X 


1— ^ 


CL 


UJ 


SCL CL CL 


u 




z r\j 


Z 


o 




UJ 




M UJ 


< 




(/!(/)«/)(/) 




2! 


X 


LL 




21 


X 


UJ IH 


OJ 


D 


X X X X 


M 




211- 




a 




H- 




M 




QL 


m CD CD CD 




(/) 


h- 1 




Q. 




D 






a 


QL 


L 


LU 


M 




-1 


LU 


O) X 




-1 




LL 


CL 




H 


CL 


< LU 




z: 




Z] 


C/) 


c^2: 


(/) 


< 


A ' A 


ck: 




0^ M 


t/) 




X X X X 




> 


<l- 


LU 




o o o o 




LU 




U 












□ 






f 






CL 




V V 






















© 



a- 



CM 




V 


1 


II 




-J 






11 


< 








> 






> 


C^ 








LU 






M X) 




1- 




-J 


ZUJ 






CLQ^ 


M2: 


UJ 




(/)□ 


M 






U. 


LUH 


< 




> 








UJ X 


M 1 






V o 




CD 




^ -Q 








</) + 


l-LU 






XMLU 


ZX 






□ 


<M 


CLU 




CDUi^ 


CKH 


C3) 




CK — 








nuj X 




VI 








1 



> 

OLU 
LU V 

!-(/) - 
C](l IDX 
UJQi^H 
Ufr-Z3 
>^ < 

ZO^LU 
LUL3CD 
LDLLl-H 

< z:^ 

^XUJ 
CDDI- 
QdCD(/) 
U >- 

UJH 

a 

X vi- 
uu 

<<Ck^ 
HCDd 

< L3 ^ 
2 X 

" M a 

LUa CD 

auj> 

Z-JGD 



□ X 

Lua 

I- CD 

>UJ 
CKX 
Ul- 









o: 


UJ 




L3 


CL 
>- 


^z 
<u 


1- 
X 


X 
CD 
CD 


c 

CO 


□ 


Ul 


CD 




1 





Ul 


c^ 






L3 




<a 


U. 




ZiH 








0) 


X 


£]^^ X 


c 


CD 


LU< 


CJ) 


CD 
















1 





* <DQ^ 
X <UJ 

[□MUJU 




□ UJLUQl LL 
CDOULL Z 



lU H ZC^ 
ZXCKOLD 

^auJC3^u. 

□ CDUU-Z 



LU 

; ^ 
' u 



-J CD 

t/)CL 

>UJ 
UJX 

X 

"C^ o 
LULU XI 
I-D + 
CDZLU 
2:13^ 



08/28/2003, EAST version: 1.04.0000 



U.S. Patent 



Dec 15, 1998 Sheet 18 of 20 

TAMPER-RESISTANT DEVICE 



5,850,451 



CPU 



CRYPTO 
CDPRDCESSDR 




MEMORY: 



KS-dev 
<KS+dev>m-f9 
KS+swQ 
FIRM NAME 
OTHER KEYS 
& CERTS 



DEVICE # 



i 



216 



CLOCK BATTERY 



D 



-210 



TRUSTED TIME-SETTING 
ENT. (eg POST OFFICE) 

TIME-SET 
INSTRUCTION 



211, 



THE TIME IS 


NOW 


3:05PM JAN 3, 


1994 


SET YOURSELF 


AND 


PROCEED 




SIGNED, 




POST OFFICE 



TIME-SET AUTH. CERT. 



•POST OFFICE' IS A 
TRUSTED TIME-SETTER 



SIGNED. SYSTEMWIDE 
AUTHORITY 



ANY DATA STRUCTURE 
CONTAINING A CONTEMP- 
ORANEOUS TIMESTAMP 



212^ VERIFIES 

(NOTE: TIMESTAMP WILL 

BE NULL IF CLOCK 
NOT CALIBRATED. ) 



213 



JAN 3. 1994 - 3:05PM 



21 



SIGNED, DEVICE 



215 



f DEVICE MFGR'S CERT 



•DEVICE #• IS TRUSTED 
TO ISSUE TIMESTAMPS 



KS+d 



ev 



SIGNED, MFGR 



FIG 21 

SELF-CERTIFYING TRUSTED TIMESTAMP DEVICE 



08/28/2003, EAST Version: 1,04.0000 



U.S. Patent Dec. is, 1998 Sheet 19 of 20 



5,850,451 



'239 



23r 



VERSION No. 



DEVICE SERIAL ND, 



OWNER NAME 



OWNER UNIQUE ID 



KS+ OWNER 



PURCHASE DATE 



-mfgr 



232 DEVICE SERIAL NO. 

233— OWNER UNIQUE ID 



234 
235 



236 
237, 
SIGN 



ec NAME 



eol NAME 



eQ2 NAME 



eQ3 NAME 



REKEY EXPIRE DATE 



INSTRUCTION SER. No. 




230- 



TRUSTED 
DEVICE 



ec 



KE* ec 



-swo 



^235 



234 



NEW ESCROW 

REQUEST 

MESSAGES 



FIG. 23 

OWNER REKEY INSTRUCTIONS PROCESS 



08/28/2003, EAST Version: 1.04.0000 



U.S. Patent 



Dec. 15, 1998 



Sheet 20 of 20 



5,850,451 



LU 
U 

MO 

>LU V 
LUI- H 

LLQdQ. 
□ 

ai- M 

LU»-»X 
0^ ^ I- 



(O 







a 




4> 


cno 












+ + 


>- 




h- 






< 




CL 




Q 








M 


O 


X 






in 




A 


a 




LU 




1- 


+> +> 




ft, 


=] 










V V 



T 



1? 



1 



o 
in 

CM 



til 

21 
□ 
Q- 
(/) 
LU 

in 



(/) 
LU 
Zl 
C3 
LU 



L3 
LU 

LU 

ID 



m 

ZLU 

< 

LUQl 

tt:L3 

<CL 
u. >- 

□ LU 



□ 



< < 

ID 

ma 
- X 

I- < 



T 



LU 






a 








+> 


< 


(/) 


< 


-p 








1 




LU 


< 




LL 


)^ 


D 




a 


a 






i/> 






UJ 


U 




o 


H 


M 




LU 


(/) 


-J 




h- 


Zl 


CL 






ck: 


□l 




ZI 




< 












1- 









CD 



CM 



U 





a 




□ 


LL 




LL 


z 




Z 


M 


> 


M 








LU 






u 


+ 


LU 




I/) 


U) 


> 




ID 


UJ 

a 





m 







a 




X 






^- 


VI 

1 






CL 


< 




4> 
+ 
V 


1 UPGRADE 





a 

+> 

4> 

I 



I > 

liJ M 
»-|- 

H Q 
M 

. LU 



LU • 
DH 

<q: 

Q^LIJ 
L3U 

H ■ 
I 
Ol 
ZZl 

<< 



in 

CM 



LU 
U 

LU 
U 

> 

UJ 

a 



CM 



o 




L 


z 




O) 






E 


Of 


> 




LU 


OJ 




i/) 






LU 


+ 








U 






M 






> 






LU 






a 







I 

h-LD 
C^Z 

<M O Q. 

<CE in4> 
XQ£LU+ + 
HI-Z(/)t/) 

Z] OC^ 

a cu< 

LL^^CL 

















CL 


z 


Z 




-P 


□ 


< 




4> 

1 


M 


- 


> 


H 


LDX 


OJ 




U 


1- 






< 


inz) 








* < 




z 


CL 






< 


^- u- 






TR 









3 



I 


(M 




Z3 




< 












UJ 








Zl 








u 





1 



< 




> 




a 


OJ 


< 


LL 




a 


z 


1 




M 




uo 






z 


LU 




< 


PI 






ZD 











o 

CM 



LU 




U 






O) 


> 




LU 


e 


Q 


A 




> L 


U 


> OJ COO 


LU 




h- 


Tl-h E W 




1 (/)+ + 


Zl 








^- 






CM 








CM 



08/28/2003, EAST Version: 1.04.0000 



5,& 

1 

ENHANCED CRYPTOGRAPHIC SYSTEM 
AND METHOD WITH KEY ESCROW 
FEATURE 

CROSS-REFERENCE TO RELATED 
APPLICAnON 

This is a division of application Ser No. 08/272,203, filed 
Jul. 8, 1994, abandoned, which is a continuation-in-part of 
application Ser. No. 08/181,859, filed Jan. 13, 1994, now 
abandoned. 

BACKGROUND OF THE INVENTION 

This invention relates to cryptographic communications 
systems. More particularly, this invention relates to the 
secure generation^ certification, storage and distribution of 
cryptographic keys used in cryptographic communications 
systems. Still more particularly, this invention relates to a 
system of cryptographic key escrow and public-key certifi- 
cate management enforced by a self-certifying chip device. 

The development and proliferation of sophisticated com- 
puter technology and distributed data processing systems 
has led to a rapid increase in the transfer of information in 
digital form. This information is used in financial and 
banking matters, electronic mail, electronic data interchange 
and other data processing systems. TransmLssion of this 
information over unsecured or unprotected communication 
channels risks exposing the transmitted information to elec- 
tronic eavesdropping or alteration. Cryptographic commu- 
nications systems preserve the privacy of these transmis- 
sions by preventing the monitoring by unauthorized parties 
of messages transmitted over an insecure channel. Crypto- 
graphic communications systems also ensure the integrity of 
these transmissions by preventing the alteration by imau- 
thorized parties of information in messages transmitted over 
an insecure channel. The cryptographic communications 
systems can farther ensure the integrity and authenticity of 
the transmission by providing for recognizable, unforgeable 
and document-dependent digitized signatures that can pre- 
vent denial by the sender of his own message. 

Cryptographic systems involve the encoding or encrypt- 
ing of digital data transmissions, including digitized voice or 
video transmissions, to render them incomprehensible by all 
but the intended recipient. A plaintext message consisting of 
digitized sounds, letters and/or numbers is encoded numeri- 
cally and then encrypted using a complex mathematical 
algorithm that transforms the encoded message based on a 
given set of numbers or digits, also known as a cipher key. 
The cipher key is a sequence of data bits that may either be 
randomly chosen or have special mathematical properties, 
depending on the algorithm or cryptosystem used. Sophis- 
ticated cryptographic algorithms implemented on computers 
can transform and manipulate numbers that are hundreds or 
thousands of bits in length and can resist any known method 
of unauthorized decryption. There are two basic classes of 
cryptographic algorithms: symmetric key algorithms and 
asymmetric key algorithms. 

Symmetric key algorithms use an identical cipher key for 
both encrypting by the sender of the communication and 
decrypting by the receiver of the communication. Symmet- 
ric key cryptosystems are built on the mutual trust of the two 
parties sharing the cipher key to use the cryptosystem to 
protect against distrusted third parties. The best known 
symmetric key algorithm is the National Data Encryption 
Standard (DES) algorithm first published by the National 
Institute of Standards and Technology. See Federal Register, 
Mar. 17, 1975, Vol. 40, No. 52 and Aug. 1, 1975, Vol. 40, No. 



2 

149. The sender cryptographic device uses the DES algo- 
rithm to encrypt the message when loaded with the cipher 
key (a DES cipher key is 56 bits long) for that session of 
communication (the session key). The recipient crypto- 

5 graphic device uses an inverse of the DES algorithm to 
decrypt the encrypted message when loaded with the same 
cipher key as was used for encryption. However, the 
adequacy of symmetric key cryptosystems in general has 
been questioned because of the need for the sender and the 

JO recipient to exchange the cipher key over a secure channel 
to which no unauthorized third party has access, in advance 
of the desired communications between the sender and 
recipient. This process of first securely exchanging cipher 
keys and only then encrypting the communication is often 

15 slow and cumbersome, and is thus unworkable in situations 
requiring spontaneous or unsolicited communications, or in 
situations requiring communications between parties unfa- 
miliar with each other. Moreover, interception of the cipher 
key by an unauthorized third party will enable that party to 

20 eavesdrop on both ends of the encrypted conversation. 

The second class of cryptographic algorithms, asymmet- 
ric key algorithms, uses different cipher keys for encrypting 
and decrypting. In a cryptosystem using an asymmetric key 
algorithm, the user makes the encryption key public and 

25 keeps the decryption key private, and it is not feasible to 
derive the private decryption key from the pubhc encryption 
key. Thus, anyone who knows the public key of a particular 
user could encipher a message to that user, whereas only the 
user who is the owner of the private key corresponding to 

30 that public key could decipher the message. This public/ 
private key system was first proposed in Diffie and HeUman, 
"New Directions in Cryptography," IEEE Transactions on 
Information Theory, November, 1976, and in U.S. Pat. No. 
4,200,770 (Hellman et al.), both of which are hereby incor- 

35 porated by reference. 

An early type of asymmetric key algorithm allows secure 
communication over an insecure channel by interactive 
creation by the communicating parties of a cipher key for 
that session of communication. Using the asymmetric key 

40 algorithm, two interacting users simultaneously and inde- 
pendently generate a secure cipher key that cannot be 
deduced by an eavesdropper and that is to be used sym- 
metrically to encode that session of communications 
between the users. This interactive method of generating a 

45 secure cipher key was described by DifiBe and Hellman in 
their 1976 paper. Under this prior art method, known as the 
Interactive Diffie-Hellman scheme, shown in FIG. 2, each of 
the two users A,B randomly chooses a secret number 21,22 
and then computes an intermediate number 23,24 using two 

50 publicly-known numbers and the secret niunber 21,22 cho- 
sen by that user. Each user next transmits the intermediate 
number 23,24 to the other user and then computes the secret 
(symmetric) cipher key 25 using his own secret number 
21,22 and the intermediate number 24,23 just received from 

55 the other user. The interactively generated cipher key 25 is 
then used symmetrically by both users as a DES or other 
symmetric cipher key to encrypt and decrypt that session of 
communications over an otherwise insecure channel in the 
manner of symmetric key algorithm communications. This 

60 interactive process requires only a few seconds of real time, 
and all digital communications, including digitized sound or 
video transmissions, in a particular session can be encrypted 
merely by pushing a button at the outset of a session to 
initiate tlie interactive key exchange process. Because all the 

65 numbers chosen in the Interactive Diffie-Hellman key gen- 
eration scheme are very large, the computations are infea- 
sible to invert and the secret cipher key cannot be computed 
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by an eavesdropper, thus preserving the privacy of the 
communication. Because the computations are infeasible to 
invert, each user knows that any communication received 
using this algorithm was not altered and could have been 
sent only by the other user, thus preserving the integrity and 
authenticity of the communication. This interactive key 
exchange method, however, requires the parties to interact in 
real time in order to create the cipher key and may not be 
useful for unsolicited communications or unfamiliar parties. 
In particular, the Interactive Diffie-Helhnan key exchange 
scheme does not work for storc-and-forward electronic-mail 
style messaging or for long-term storage of documents in an 
electronic data storage system, because the recipient is not 
on-line to negotiate the session key. 

A modified, non- interactive form of the Diffie-Hellman 
scheme, known as Certified DifiBe-Hellman, can be used 
when the communicating parties are not on-line together. 
ITie initial, certification step of the Certified DifiBe-Hellman 
session key generation scheme is shown in FIG. 3, One user, 
the recipient-to-be, randomly chooses a secret number 31 
(his private key) and then computes an intermediate number 

33 using two publicly-known numbers 32 and the secret 
number 31 chosen by that user. That user then sends proof 
of identification along with the intermediate number and the 
two public numbers, which numbers together form his 
public key 34, to a certifying authority that then issues a 
public key certificate 35 digitally signed 36 by the issuing 
certifying authority binding the user's identity to the user's 
DifiSe-Hellman public key information 34. The public key 

34 publicized by that user remains the same until he decides 
to rekey and choose another private key 31. Messaging using 
the Certified DiQ5e-Hellman method is shown in RG. 4. In 
order to transmit a message to that user, a sending user first 
obtains the receiving user's certificate 35 and verifies the 
certifying authority's signature 36. The sender next com- 
putes the session key 42 for that communication session 
using the recipient's intermediate number 33 (from the 
recipient's certificate) and the sender's own secret number 
41 (his private key), which he chooses at random. The 
sender then encrypts a message 43 using the session key 42 
and places his own intermediate number 40 unencrypted at 
the head of the communication. Upon receiving the 
communication, the recipient computes the session key 42 
using the sender's unencrypted intermediate number 40 and 
his own secret number 31 (or private key), and then uses the 
session key 42 to decrypt the message 43. As with the 
Interactive DifiSe-Hellman scheme, the session key gener- 
ated in the Certified DifiBe-Hellman scheme is then used by 
both parties to encrypt and decrypt communications during 
that session over an otherwise insecure channel using a 
conventional symmetric algorithm, such as DES. The Cer- 
tified Diffie-Hellman scheme, however, requires that a 
trusted entity or a certifying authority sign the receiving 
user's public key certificate so that a sending user can trust 
that the information contained within is correct. In addition, 
the private key randomly chosen by the sender, with which 
he computes both the session key and the intermediate 
number for that ooramunication, must not be identical to the 
private key that is connected to the sender's own public key 
certificate; in order to avoid others learning his permanent 
private key numbers (corresponding to the pubHc key num- 
bers that have been certified), the sender should keep them 
distinct from any ephemeral private keys or intermediate 
numbers that are generated only for specific messages. 

Another asymmetric key algorithm, named the RSA algo- 
rithm after the inventors Rivest, Shamir and Adleman, is 
described in U.S. Pat. No. 4,405,829 (Rivest et al.), which is 
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hereby incorporated by reference, and involves the diflSculty 
of factoring a number that is the product of two large prime 
numbers. As with the Interactive DifiBe-Hellman scheme, the 
RSA algorithm is relatively straightforward to compute but 
practically infeasible to invert. Thus, it is not feasible to 
derive the private key from the public key and, in this way, 
the privacy of the communication is preserved. Once a 
message is encrypted with the public key using the RSA 
algorithm, only the private key can decrypt it, and vice 
versa. As with the Certified DifiBe-Hellman scheme, the RSA 
algorithm requires a trusted entity to certify and publicize 
the users' public keys. In contrast to both DifiSe-Hellman 
schemes, however, the RSA algorithm does not itself gen- 
erate a "session key" to be used symmetrically by the 
parties. Instead, the public encryption key for a particular 
user directly encrypts communications to that user and that 
user's private decryption key decrypts those communica- 
tions encrypted with the user's public key. In this way, the 
RSA algorithm is a pure asymmetric key algorithm. 

However, because the RSA algorithm is complex and 
involves exponentiation of the message by very large 
numbers, encrypting or decrypting a message of even mod- 
erate length using the RSA algorithm requires a great deal of 
time. Thus, it is much simpler, faster and efficient to use the 
RSA asymmetric algorithm to transport a DES cipher key 
for use in a symmetric algorithm. This prior art mode of 
operation is known as RSA key transport and is shown in 
FIGS. 5 and 6. For example, referring to FIG. 5, a user could 
generate a random DES key 51 and encrypt a message 52 
with that DES key. The user would then encrypt the DES key 
51 with an intended receiving user's public RSA encryption 
key 53 and transmit the DES-encrypted message 54 along 
with the RSA-encrypted DES key 55 to the receiving user. 
After receiving the transmission, as shown in FIG. 6, the 
recipient decrypts the DES key 51 using his private RSA 
decryption key 56 and uses that DES key 51 to decrypt the 
message 52, Because the DES algorithm requires much less 
time and expense to compute than does the RSA algorithm, 
the symmetric DES key is used to encrypt and decrypt the 
actual message, while the asymmetric RSA keys are used to 
encrypt and decrypt the symmetric DES key. 

The RSA public/private key cryptosystem also provides 
for a digital "signature" that is both message dependent and 
signer dependent, and can be used to certify that the received 
message was actually sent by the sender and that it was 
received unaltered. RSA digital signature is based on the 
additional property of RSA that, in addition to allowing the 
user's private key to decrypt only those communications 
encrypted using that user's public key, permits a user's 
private key to encrypt messages that can be decrypted only 
by that user's pubHc key. Because only the user has the 
private key, use of the private key to encrypt aUows for proof 
of origin that can be verified by anyone with access to the 
user's public key. In practice, the sender first uses his private 
key to encode the message text into a signed message, which 
can be decrypted by anyone but could have come only from 
the sender. If desired, the sender may then optionally use the 
recipient's public encryption key to encipher the signed 
message to be transmitted. Upon receipt of the ciphertext, 
the recipient decrypts the ciphertext with his private decryp- 
tion key, if necessary, and decodes the signed message with 
the sender's public encryption key. Because only the sender 
knows his unique private key, only the sender could have 
sent the particular "signed" message; the signature thus 
verifies the identity of the sender. Also, because the recipient 
has only the sender's public key, the sender cannot claim 
that the recipient or an unauthorized third party altered or 



08/28/2003, EAST Version: 1.04.0000 



5,850,451 

5 6 

fabricated his message; the signature thus prevents repudia- between multiple hierarchies, and (3) a "local trust" model, 
tion of the message by the sender. Furthermore, because These models are described in detail in the standards docu- 
only the sender's private key transforms the original mcs- ment American National Standard X9, 30, "Public Key Cryp- 
sage and only the sender knows his unique private key, tography Using Irreversible Algorithms for the Financial 
neither the recipient nor an unauthorized third party could s Services Indastry: Part 3: Certificate Management for DS A" 
have altered the message; the signature thus certifies the (American Bankers Assn., Washington, D.C., 1992), which 
integrity of the message. is hereby incorporated by reference in its entirely. Although 
The RSA algorithm also provides for another type of there is not yet a general consensus as to which of the 
digital signature that uses a hashing function to create a short above-mentioned trust models is best, it is assumed through- 
message digest that is unique to each document. FIGS. 7 and out this disclosure that an appropriate, generally accepted 
8 show RSA signature creation and RSA signature certification trust model wiU be estabhshed and adhered to 
verification, respectively, using a hashing function. A hash- whenever certificates issued by more than one entity are 
ing function is another complex mathematical algorithm that involved. 

is "one-way," i.e. so thai it is infeasible to reconstruct the The public/private key system described above takes into 

document from the hash result, and is "collision-free," i.e. so account the privacy interests of the users who wish to 

that it is infeasible to produce another document that will transmit and receive communications privately. In addition, 

hash to the same digest. As shown in FIG, 7, the sender first however, there are also the law enforcement and national 

passes the message 72 through a hashing algorithm 73 to security interests of governments to be considered. The 

produce the message digest 74 and then encrypts the digest ability of the government to monitor or eavesdrop on 

with his RSA private key 75, forming a compact digital 20 otherwise private electronic transmissions for law enforce- 

signature 76 that is attached to the message 72. After ment and national security purposes must be preserved so 

receiving the transmission of the message 72 and the mes- that suspected criminals, terrorists and foreign spies are not 

sage digest 76, as shown in FIG. 8, the recipient decrypts the permitted to conspire beyond the reach of the law. Whereas 

sender's RSA encrypted message digest 76 (the digital telephone communications can be monitored through 

signature) using the sender's RSA public key 77. The 25 wiretapping, cryptographic algorithms make the enciphered 

recipient also uses the same hashing algorithm 73 to produce data unable to be deciphered even by powerful code- 

a message digest 74 from the received message. The two breaking computers. The increase in the volume and per- 

message digests resulting from the two transformations centage of digital and digitized transmissions encrypted with 

performed by the recipient should be identical, thus verify- advanced algorithms will, therefore, serve to frustrate and 

ing that the message was signed by the sender. 30 thwart the lawful government electronic surveillance of 

Another system of digital signature, called DSA for these communications, especially if cryptographic devices 

Digital Signature Algorithm, may also be used for sender are widely implemented in telephones, computers, facsimile 

verification. The DSA Algorithm was disclosed in U.S. machines and all other data processing equipment, 

patent application Ser. No. 07/738,431, which is hereby One way to enable the government or other authorized 

incorporated by reference in its entirety. The DSA Algorithm 35 investigators to monitor communications of suspected 

has properties that are similar to those of the RSA signature criminals is to require all users of cryptographic communi- 

algorithm in that the sender passes the message through a cations to escrow their private decryption keys with either a 

hashing algorithm to produce a message digest and then private authority or the government, i.e. allow either the 

encrypts or signs the message digest using his private key; private authority or the government to be the trusted custo- 

the recipient verifies the encrypted digest using the sender's 40 dian of the iisers' private decryption keys. When necessary 

public key. However, unlike the RSA signature algorithm for surveillance, the government then will have access to or 

that returns the original message digest when the recipient will be able to gain access to the private keys in order to 

decrypts the signature block, the DSA verification algorithm monitor all encrypted communications. This method, 

results only in a positive confirmation of the validity of the however, is unworkable because it contains insufficient 

signature; communications encrypted using an intended 45 safeguards against abuse by the government of the private 

recipient's public key cannot later be recovered by decryp- decryption keys and against possible leaking of the private 

lion with the recipient's corresponding private key. For this decryption keys to unauthorized third parties either by theft 

reason, the DSA algorithm may be used quite capably for from the government or the private authority or by corrup- 

digital signatures, but not for key transport or for direct tion of government or private authority personnel, 

message encryption. 50 Another method of escrowing private decryption keys to 

In order for the public/private key system to operate preserve both user privacy interests and law enforcement 

eflBciently, users must trust a centralized key certifying security interests is by using a system such as the method 

authority to be responsible for publicizing and updating a described in "Fair Public Key Cryptosystems," proposed by 

directory of public encryption keys. The key certifying Silvio Micali at CRYPTO 92 in March, 1993 and published 

authority must be trusted by all users, both senders and 55 by the Laboratory for Computer Science of the Massachu- 

recipients, to distribute the correct public keys for all users setts Institute of Technology on Oct. 13, 1993, and in U.S. 

so that no messages are transmitted to unintended recipients. Pat. No. 5,276,737, both of which are hereby incorporated 

To this end, as discussed above and elaborated below, the by reference. By this method, shown in FIGS. 9-11, a user 

certifying authority would distribute each user's name and who wishes to certify his public key for encryption purposes 

public encryption key information, and would affix its own 60 must escrow his private key in the following manner. As 

digital signature to the distributed information in order to shown in FIG. 9, the user first breaks his private key 91 mto 

certify the correctness of the information. However, when several "pieces" 92, each of which can be individually 

more than one entity, or a hierarchy of entities, is involved verified 90 to be a valid part of the complete private key 91. 

in the certification process, there are several different meth- The private key can be reconstructed only with knowledge 

odologies or "trust models" for determining how a user will 65 of aU the pieces or some specified number of them. The user 

process the certificates. The three main models are (1) a pure then sends 93 each piece to a different escrow agent or 

hierarchical model, (2) a model using cross-certification agency 94, who, as shown in FIG. 10, verifies 95 the piece 
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as a correct part of the private key 91 using a special When users of Clipper chip devices wish to communicate, 

algorithm and communicates this verification 96 to a master they first agree on a symmetric session key with which to 

escrow center. Referring to FIG. 11, after receiving vcrifi- encrypt the communications. Any method of deriving the 

cation 96,97 that each piece of the private key is correct, the symmetric session key, such as Interactive DifBe-Hellman 
master escrow center can then issue a certificate 98 for the $ key derivation process, and any method of transporting the 

user's public key 99, allowing it to be used in a privacy DES session key between users, such as RS A transport, may 

system with the assurance that, if need be and pursuant only be used. At the start of each commuaication, each user sends 

to a warrant or court order, law enforcement agencies will be to the other a Law Enforcement Access Field (LEAF) that 

able to obtain the secret pieces of the private key from the contains enough information to allow law enforcement 

user's chosen escrow agents, recombme them and momtor agents to wiretap or monitor the communication. The 

the communications of that user. By this system, users can believed format of the Clipper LEAF is shown in FIG. 13 

be assured of the privacy of their encrypted transmissions, ^^^^^ y^^^^^^ ^^^^^ LEAF format, 

and government can be assured of iLs abihly to gam access ^^^^^^^ verification are currently classified "secret" by 

to encrypted transmissions upon a showing of need. Because ttc- * i- * j i_ 

-^'^ u u * .u 1 « the U.S. government, this discussion and FIG. 13 are both 

no one entity normally ever has access to the complete .7 1.. \r„o urr^*^. 

private key and because the user chooses entiUes that he somewhat speculative), lo form the LEAF, the session key 

trusts, the chances ofunlawful or corrupt actions are greatly ^ first encrypted using the private device key; then the 

reduced. Also, because a wider range of entities would be device-key-encrypled session key, the sender device's serial 

eligible as escrow agents, the chances of simultaneously number and a checksum (a verifying value) of the original 

compromising all the escrow agents, and thereby disrupting unencrypted session key are together encrypted with the 
all trusted commerce, is even further reduced. 20 Clipper family key to complete the LEAF. The message is 

The master escrow center, as a trusted authority certifying then encrypted using the chosen session key. The session- 

the authenticity of the user's public key, periodically issues key-encrypted message and the family -key-encrypted LEAF 

a publicly-available certificate attesting or notarizing the are together transmitted to the recipient. Upon receiving the 

connection between the public encryption key and its own- communication, the receiving user first loads the received 
er's identifying information. The certificate of authenticity 25 LEAF into his Clipper chip in order to check whether the 

assures the sender that transmissions to that named public LEAF is valid and whether the session key encrypted within 

key user will in fact be received and read only by the the LEAF matches the session key previously received. If 

intended recipient. The certificate is usually in an interna- the LEAF is valid, the Clipper chip will decrypt the message 

tionally recognized electronic formal, such as the one speci- with the chosen session key that was previously received, 
fied in CCITT Recommendation X.509 and i^ued as an 3^ ^j^w enforcement agent lawfiiUy wiretapping or moni- 

mternauonal standard by the International Standards Orga- ^^e communication, however, does not know the 

nization (ISO). An example of a public encryption key ^^^^-^^ ^ ^^^^ ^^^^ ^ ^1^^ LEAF in order to 

escrowcertificatefomiatisshownmFIG U^Tlie^^^^^ ^^^^^ the session key. T^e agent intercepts the desired 

contains, among other things, the name of the orgamzatioo tt-at^ j * ■ *u ^^f- r -i . j 

or key management center that created the certificate (the decrypts it using the Clipper famdy key ^d then 

issuer) 121, the owner's pubUc key 122, the owner's iden- presents the chip serial number from the LEAF and a 

tifying information 126, a certificate serial number 123, and courtnordered warrant or other legal authorization to the two 

validity starting and ending dates 124. The issuer's digital government escrow agents, receivmg in return the two key 

signature 125 "seals" the certificate and prevents its alter- sp^its of the wirc-tappcd user's private device key. The agent 

ation. combines the two escrowed device key components and uses 

The U.S. government, however, has proposed as a gov- 40 the resulting device key to decrypt the device-key-encrypted 

emment (and possible industry) standard another method to session key from the LEAF. The session key can then be 

enable it to escrow private decryption keys and to monitor used to decrypt the actual messages from the communica- 

communications. The U.S. government has developed a tions. The requirement that the sender and recipient each 

microcircuit, called the "Clipper chip," that can be built into create a LEAF and validate the other's LEAF insures that 
government and commercially-produced telephones and 45 law enforcement agents will have a reasonable chance at 

computer devices. The Clipper chip is a low-cost chip that intercepting the LEAF, since each LEAF is expected to pass 

may be used for bulk encryption and key management; the between the users over the same communications medium. 

Capstone chip is a more advanced version of the Clipper Further, it allows law enforcement to selectively monitor 

chip that adds digital signature and message digest capa- only one suspected user by decrypting the LEAF generated 
bilities. Like other encryption systems, the Qipper chip uses so by that user, regardless of which user originated the com- 

a symmetric encryption algorithm, albeit a classified algo- munication. 

rithm called Skipjack, that scrambles telephone and digital Unfortunately, there are many technical problems with the 

computer data communications in a manner similar to DES, government's Clipper chip proposal, mostly stemming from 

but using an 80-bit key. Each Clipper chip has a unique serial the fact that the private keys to be escrowed are permanently 
number, a Clipper family key common to all Clipper chips 55 embedded in the Clipper chips during manufacture. Because 

and its own symmetric private device key that will be needed the private encryption key for a particular device is burned 

by authorized government agencies in order to decode into the chip and cannot be changed, the chip and probably 

messages encoded by a device containing the chip. When the the entire device that contains it must be discarded if 

device containing the chip -is manufactured, the unique compromised. It is preferable for the user of a particular 
private device key will be split into two components (called 60 device to be able to rekey, rcescrow and recertify the device 

"key splits") and deposited separately with two key escrow at will if compromise is suspected or at regular intervals to 

data bases or agencies that will be established within the avoid potential compromise. In addition to the inability of 

government. Law enforcement agents can gain access to the user to rekey and reescrow, the user of the Clipper device 

these private device keys by obtaining a warrant or other has no choice of the number or the identities of the key 
legal authorization to wiretap or monitor the communica- 65 escrow agents employed by the government to safeguard his 

tions and by presenting the warrant to the two escrow private key. Instead, the private key spUts are deposited in 

agencies. two escrow data bases or agencies established by the gov- 
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emmeni. Users may not trust the Clipper chip devices due to 
the risk that the government may have complete access to 
any transmission or transaction through the device, access 
that could be abused or corrupted. Users may also desire that 
their keys be escrowed with more trustees than the govern- 5 
ment provides, in order that their private keys will be more 
secure. If the concept of key escrow is to have significance, 
each user must be able to choose his own trustees with 
whom to escrow his private keys, based upon the level of 
trust desired. 

Also, it is believed that the government Clipper system 
allows users to communicate only symmetrically and in real 
time, and does not provide any direct support for store-and- 
forward electronic-mail type messaging. Prior to encrypting 
communications, the sender and recipient must first agree on 55 
a symmetric session key with which to encrypt the commu- 
nications. Typically, this key exchange is done using the 
Interactive Diffie-HcUman scheme, the only key exchange 
method believed to be supported by the Clipper chip. Thus, 
unless they wish to arrange their own key management 20 
system, u.sers are restricted to simultaneous, interactive 
communications, such as real-time voice or facsimile com- 
munications. In order to use store -and-forward electronic- 
mail type messaging, however, a user must be able to access 
the intended recipient's public key, such as by using a 25 
Certified Dififie-Hellman or a certified RSA key transport 
scheme, even if the intended recipient is not available for an 
interactive on-line communication. Because it is believed 
that the government's Qipper system does not facilitate this, 
store -and-forward messaging is difficult. The government*s 30 
proposed standard system thus may tend to limit the com- 
munications capabilities of users to on-line interaction. 

Moreover, under the government system, the users* 
employers have no access to the encrypted data or trans- 
missions of their employees. Employers, on whose behalf 35 
the employees are developing, communicating or transmit- 
ting confidential or proprietary data, must retain the right to 
gain access to their employees* data or transmissions. Many 
situations could arise wherein encrypted information would 
be available only to the specific employees directly engaged 40 
in using the cryptographic systems and not to the manage- 
ment or boards of directors who are responsible for those 
employees and who own the corporate data resources. By 
encrypting data or communications, employees could 
develop or appropriate for themselves new programs, prod- 45 
ucts and technologies or could conduct illegal activities and 
transactions, all without their employers* knowledge. Also, 
movement or reorganization of staff and changes of storage 
facilities could result in the loss of massive amounts of 
information that was important enough at the time of 50 
encryption to be encrypted. See Donn B. Parker, "Crypto 
and Avoidance of Business Information Anarchy** (Invited 
speaker presentation at First Annual AC Conference on 
Computer and Communication Security, Nov. 3-5, 1993, 
Reston, Va.), which is hereby incorporated by reference. 55 
Aside from the originator of the data or the sender of the 
transmissions, the Clipper chip allows only the government 
to have access to the transmissions. Although employers 
could seek a court-issued warrant in order to monitor their 
employees* commimications, employers may wish to moni- 60 
tor their internal officers in a more discreet fashion than by 
initiating a federal investigation any time suspicion is 
aroused. 

Furthermore, mandating a classified algorithm that is 
embedded in the chip and thus available only in hardware 65 
and only from government-authorized chip manufacturers 
injects the government into the rapidly changing and highly 
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competitive market for communications and computer hard- 
ware. A government agency or a government-authorized 
manufacturer may be unable or unwilling to design and 
market advanced devices and products specially tailored for 
particular companies as would a private manufacturer. If the 
government authorizes only certain vendors to manufacture 
the chips having the classified algorithm, competition will 
be reduced and the technology will be prevented from being 
incorporated into other products. Additionally, because the 
details of the Skipjack algorithm have not been made public, 
suspicion has arisen as to whether the algorithm could be 
insecure, due either to an oversight by its designers or to the 
deliberate introduction by the government of a trap door. An 
important value of cryptosystem design is that the privacy 
and security of the encrypted messages should depend on the 
secrecy of the relevant key values, not on the secrecy of the 
system's details. 

It is, therefore, desirable to provide a commercial key 
e.scrow system that uses published algorithms, operates in a 
manner that iaspircs the users' trust and confidence, and 
solves the problems posed by national security and law 
enforcement demands. 

It is also desirable to provide a commercial key escrow 
system that uses private keys that may be changed by the 
user at will or at regular intervals. 

It is further desirable to provide a commercial key escrow 
system that allows the user to choose the key escrow agents 
to safeguard his private key or the separate pieces of his 
private key. 

It is still further desirable to provide a commercial key 
escrow system that contains safeguards against unrestricted 
government access, yet allows access by the employers of 
the users or by the countries of which the foreign users are 
citizens. 

It is also desirable to provide a commercial key escrow 
system that offers an alternative to the U.S. Government's 
proposed Clipper chip system. 

SUMMARY OF THE INVENTION 

It is one object of this invention to provide a commercial 
key escrow system that uses published algorithms, operates 
in a maimer that inspires the users' trust and confidence, and 
solves the problems posed by national security and law 
enforcement demands. 

It is another object of this invention to provide a com- 
mercial key escrow system that uses private keys that may 
be changed by the user at will or at regular intervals. 

It is a further object of this invention to provide a 
commercial key escrow system that allows the user to 
choose the key escrow agents to safeguard his private key or 
the separate pieces of his private key. 

It is still a further object of this invention provide a 
commercial key escrow system that contains safeguards 
against unrestricted government access, yet allows access by 
the employers of the users or by the countries of which the 
foreign users are citizens. 

It is yet another object of this invention to provide a 
commercial key escrow system that offers an alternative to 
the U.S. Government's proposed Clipper chip system. 

These and other objects of the invention are accomplished 
in accordance with the principles of the invention by pro- 
viding a cryptographic key escrow system that uses a 
method, such as the Micali "Fair" escrow method, for 
verifiably splitting users' private encryption keys into com- 
ponents and for sending those components to trusted agents 
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chosen by the particular users, and by providing a system FIGS. 9-11 are flowcharts that together show the steps of 

that uses modern public key certificate management, the prior art Micali key escrow process; 

enforced by a chip device thai also self-certifies. In a FIG. 12 is an example of the format for a prior art pubHc 

preferred embodiment of this invention, the new chip encryption key escrow certificate- 

encrypts or decrypts only if certain conditions are met^ 5 ^3 ^ ^^^.^^^ ^^^^^ 

namely, (1) if a valid sender cerUficatc and a vdid dipper device Law Enforcement Access Field (LEAF); 

"reap lent ceruficale" are mput, where 'valid means that J, . / 

the particular user's private decryption key is provably . FIG. 14 is an example of the format for a device certificate 

escrowed with a specified number of escrow agents and that ^s"^^. manufacturers of the device of the present 

the master escrow center is registered and certified by the 10 

chip manufacturer, and (2) if a valid Message Control FIG- 15 is a flowchart showing the steps of a method of 

Header is generated by the sender and validated by the verifiably escrowing a key with only one escrow agent; 

recipient, thereby giving authorized investigators sufficient FIG. 16 is a flowchart showing the steps of a method of 

information with which to request and obtain the escrowed verifiably escrowing a key, based on the trusted device 

keys. Because this invention relies upon a system of certifi- 15 alone; 

cate management, it can be made very flexible and inde- piG, 17 is a flowchart showing the steps of a method of 

pendentof location and time, unlike purely on-line systems. sending an encrypted message with a Message Control 

The methods for escrowing a private decryption key and Header (MCH); 

receiving an escrow certificate are also applied herein to a cir^ ib .1 «f , xxr^u doa i, * * 

J. c * X . • .... FIG. lo is an example or a MCH in RSA key transport 

more generalized case of regLstenng a trusted device with a 20 f^^^^^. ^ f 

trusted third party and receiving authorization from that V ^ . 

party enabling the device to communicate with other trusted ^^.^Z ^ flowchart showing the steps of a method of 

devices. receiving an encrypted message with a MCH; 

Afurther preferred embodiment of this invention provides example of a MCH decoder box and a 

a method for generating verifiably trusted communications 25 flowchart for its process flow; 

among a plurality of users, comprising the steps of escrow- FIG. 21 is an example of a self-certifying trusted times- 

ing at a trusted escrow center a plurality of asymmetric l^^ip device; 

cryptographic keys to be used by a plurality of users; FIG. 22 is an example of the format for a device owner 

verifying each of said plurality of keys at the escrow center; certificate issued by the manufacturer of the device of the 

certifying the authorization of each of said plurality of keys present invention; 

upon verification; and initiating a communication from each piG. 23 is a flowchart showing the steps of a method of 

of said plurality of users using a respective one of said rc-escrowing a key (rekeying) by the owner of the device of 

plurality of keys contingent upon said certification. Further the present invention* and 

embodiments of this invention provide for decoding of 24 is a flowchart showing the steps of a method for 

communications by authonzed law enforcement agents 35 ^^^^^^^^^ ^^^^^^ ^^^.^^ ^j^^ ^^^^^ ^^^^^-^^ 

based upon use of the Message Control Header included ^JJj^ ^ trusted third party, 
with each communication, using a special law enforcement 

decoder box and auditing of the law enforcement wiretaps to DETAILED DESCRIPTION OF THE 

prevent abuse by law enforcement and other officials. F\ir- INVENTION 
ther preferred embodiments provide for rekeying and 

upgrading ofdevice firmware using a certificate system, and Fu^lic key cryptosystems, including the use of digital 

encryption of stream-oriented data. signatures, can potentially be the cornerstone of the creation 

of national, or even global, paperless electronic document 

BRIEF DESCRIPTION OF THE DRAWINGS systems. Use of these systems wiU have enormous commer- 

45 cial significance in terms of costs savings. The critical 

The above and other objecU and advantages of the clement in the development and widespread acceptance of 

invention will be apparent upon consideration of the fol- these systems is the reliance placed upon the underlying 

lowing detailed descnption, taken in conjunction with the cryptosystems and the digital signatures by governments, 

accompanying drawmgs, in which the reference characters tanks, corporations and other users, including individual 

refer to like parts throughout and in which: Reliance on these systems should arise not fi-om mist 

FIGS. lA-lG are lists of symbols and abbreviations that by each user of its own internal system or of other users, but 

are used in the figures of this invention; rather from trust by each user of the public key cryptosystem 

FIG. 2 is a flowchart showing the steps of the prior art and of the certification mechanisms it provides. The com- 

Interactive Diffie-Hellman key derivation method; mercial cryptosystem of the present invention satisfies these 

RG. 3 is a flowchart showing the steps of the certification 55 concerns by using self-certifying and, therefore, tiiisted, 

portion of the prior art Certified DiflSe-Hellman method; encryption devices as the impartial arbiters of trust. 

HG. 4 is a flowchart showing the steps of the messaging ^ preferred embodimem of the present invention, the 

portion of the prior art Certified DiflBe-Hcllman method; tamper-resistant chip, or a tamper-resistant trusted device 

HG. 5 is a flowchart showing the steps of encryption ^ont^ning the chip, that performs the en^^^^ 

using the prior art RSA key transport method; and digital signature is embedded with a non-modifiable 

Jr„ „ , : . . public/pnvate signature key pair unique to that chip and with 

FIG 6 IS a flowchart showing the steps of decryptioD ^ "manufacturer's certificate." The embedded manufactur- 

usmg the prior art RSA key transport method; ^^'s certificate enables the device containing the chip (a) to 

HG. 7 is a flowchart showing the steps of signature digitally "sign" documents and communications ("data 

creation using the prior art RSA method; ^5 structures") using its own private device signature key 

FIG. 8 is a flowchart showing the steps of signature proving that they uniquely originated from that device and 

verification using the prior art RSA method; (b) to prove by appending the manufacturer's certificate to 
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documents and communications that those data structures 
can be trusted because the originating device is one of 
known and trusted type and is made by that trusted manu- 
facturer. The manufacturer's certificate in effect says, "The 
device whose private key matches the pubHc key certified 
herein is of type XXX. Signed, Manufacturer." Because the 
private signature key is embedded in a tamper-resistant 
manner and because the manufacturer is trusted, documents 
and communications issued by the device and signed using 
the private signature key will also be trusted. 

A preferred embodiment of the present invention contains 
seven major phases of use: (1) creation or manufacture of the 
chips contained in the device, (2) registration of the device's 
encryption key with escrow agents, (3) nonmal encryption 
and decryption of user messages, (4) decoding of commu- 
nications by authorized law enforcement agents, (5) rekey- 
ing and upgrading of the device by the owner or employer, 
(6) auditing of law enforcement wiretaps, (7) encryption of 
stream -oriented data, and (8) national security safeguards. 
Manufacture of the Trusted Device 

Manufacture of trusted devices of the present invention is 
based on the presence of the following general features: 

(1) An embedded microprocessor (or microcontroller), a 
miniature computer that mediates all outside access and 
performs various computational and programming opera- 
tions; 

(2) An optional cryptographic coprocessor, which can 
perform standard mathematical encrypting and decrypting 
operations at much higher speed than can a general purpose 
microprocessor and which will preferably contain a hard- 
ware noise source, such as a diode noise source, to assist in 
the generation of ccrtifiably random numbers as needed for 
cryptographic key generation; 

(3) An input-output interface or subsystem to assist in 
handling the flow of data and commands to and from the 
microprocessor, which may include a status display or 
monitor; and 

(4) A memory subsystem that may potentially employ 
several types of memory storage technology, each having a 
different characteristics of permanence and accessibility, 
such as (a) Read Only Memory ("ROM") that can contain 
permanent and unchangeable programs and data, (b) Elec- 
trically Erasable Programmable Read Only Memory 
("EEPROM") or "FLASH" memory, that can contain semi- 
permanent programs and data, i.e. they can be changed but 
nevertheless are not lost when device power is lost or shut 
off, and (c) Random Access Memory ("RAM"), which can 
be used for temporary calculations and temporary data 
storage but is lost when power is shut off. 

The entire device is designed and manufactured in such a 
way that all its elements, including especially the permanent 
and semi-permanent memory areas, are shielded from tam- 
pering that might reveal their contents or alter their modes 
of operation. One way to shield the device elements from 
tampering is through the use of special coatings that are 
difiBcult to remove without destroying the information that 
underlies the coatings. In addition, there are other features 
that can cause the memory to be erased if any aheration to 
the physical enclosure of any of the memory areas is 
attempted or if suspicious actions thai may signal tampering 
attempts, .such as cooling the device to abnormally low 
temperatures in an attempt to deactivate and defeat the 
device's internal defense mechanisms, occur. Some of these 
protective features may require a constant source of battery 
power, such that the device can take electrical actions to 
delete important data if tampering is suspected. The present 
invention does not specify any particular preferred method 
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of making the devices tamper-resistant, but rather relies on 
existing or future technologies that may be or may become 
generally regarded as providing an acceptable degree of 
protection from unauthorized disclosure or modification of 

5 the data contained in the devices. A device with such 
characteristics is sometimes referred to as a tampcr-rcsistant 
secure module (TRSM), of which a current example is the 
Clipper/Capstone device, discussed earlier, commercially 
available from Mykotronx, Inc. 

10 The manufacturer of the chips may be any of the many 
major computer microprocessor chip manufacturers. The 
manufacturer should preferably be one who is known to the 
cryptographic industry and is trusted with respect to chip 
quality and security and the integrity of its manufacturing 

15 process. 

The chips manufactured in order to be used in an embodi- 
ment of this invention would include the following capa- 
bilities. The chip would first include an embedded device 
public/private key pair for device signatures to be issued by 

20 the device, where the private signature key is non-readable 
and tamper-resistant. The cryptographic signature keys may 
be of any acceptable cryptographic type, such as RSA. 
However, because RSA has both encryption and signature 
capabilities and because it is desirable to isolate the signa- 

25 ture and encryption processes, the cryptographic signature 
key should preferably be DSA. The chip would also include 
an embedded and tamper-resistant manufacturer's certificate 
for the device signatiu-e key, an example of the format for 
which is shown in FIG. 14. The device containing the chip 

30 can append this certificate to its signatures in order to prove 
that the signatures originated from a device of known and 
trusted type having the qualities described below. 

A chip manufactured for use in an embodiment of the 
present invention would also include the manufacturer's 

35 public signature verification key embedded within the chip 
in a tamper-resistant manner. The manufacturer's public 
signature key can be used by the user to verify instructions 
received from others by checking whether those instructions 
have attached a valid digital signature created by the manu- 

40 facturer's private signature key, in order to determine 
whether those instmctions originated with the manufacturer 
or one trusted by the manufacturer. The chip may also 
include embedded and tamper-resistant public instructions 
keys that can be used by the user to verify instructions 

45 received from others. The public instmctions key could be 
the public key of some other trusted entity, such as Bankers 
Trust Co., selected by the manufacturer or could be the 
public key of a trusted national or global system-wide 
authority, and may optionally be embedded into the chip by 

50 the manufacturer for use as a "short-cut" to avoid having to 
verify the extra manufacturer-to-trusted-entity certificate. 
The manufacturer could install several instruction keys of 
various qualified key escrow houses that the manufacturer 
selects and believes to be capable and tmsted. 

55 Furthermore, the chip used in an embodiment of the 
present invention would have the ability to generate a 
pubUc/private key pair for encryption and decryption of data 
and communications by the individual user. The crypto- 
graphic encryption keys may be of any acceptable asym- 

60 metric cryptographic type, such as RSA. The cryptographic 
keys should, however, preferably be of the DifiBe-Hellman 
type, i.e. the user's secret number is the private key and the 
user's publicized intermediate number is the public key, 
which are together used in the Certified Dififie-Hellman 

65 scheme to generate a session key that is used to encrypt and 
decrypt commimications. The private key so generated is 
then stored inside the chips in a non- readable and tamper- 
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resistant manner. In addition, the chip would also have the 
ability, once a public/private encryption key pair for that 
device has already been generated, to rekey and generate a 
new public/private encryption key pair in place of the 
previous key pair. In another embodiment, Interactive 5 
DifBe-Hellman key generation can also be tised, as discussed 
later, in order to ensure that all senders and recipients 
contribute new random numbers to generate the message 
session keys. 

In the preferred embodiment of this invention, the trusted lo 
device will have the ability to decrypt encrypted communi- 
cations only on two conditions. The first condition is that 
valid master escrow center certificates for both the sending 
and the recipient devices must have been fed into the device 
prior to its receiving the encrypted transmission. Each 15 
certificate is valid if it is signed by a master escrow center 
certifying that the private decryption key of that device has 
been escrowed with one or more qualified escrow agents, 
and preferably with two or more Micali -style agents that 
employ a verifiable key-splitting protocol. This master 20 
escrow center certificate either must be accompanied by 
another certificate issued by the manufacturer establishing 
the named master escrow center as a valid escrow agent, or 
must be signed by a third party (a trusted national or global 
system-wide authority) named as a holder of a public 25 
instructions key embedded into the chip by the manufac- 
turer. The second condition for decryption is that the mes- 
sage to be decrypted must be preceded by a valid Message 
Control Header (MCH) data field (the format for which will 
be described later) so that law enforcement or employer 30 
security personnel will have sufficient data from which to 
obtain the recipient's escrowed private keys and therevnth 
monitor the communication. 

In another embodiment of this invention, the chip will 
also have the ability to generate a public/private key pair to 35 
be used for user signatures, distinct from the embedded key 
pair that is used for device signatures. As with the device 
signature key pair, the cryptographic user signature keys 
may be of any acceptable cryptographic type, such as RSA, 
but should preferably be DSA, again to avoid any possible 40 
confusion with the keys used for message encryption. The 
user signature private key should be non-readable and 
tamper-resistant. The user would use the signature private 
key to sign his communications for sender verification and 
non-repudiation purposes. In still another embodiment of 45 
this invention, the chip also has the ability to use the device 
signature key in order to sign a request for certification of the 
user public signature key that it has generated for the user, 
thus proving that the user signature key pair was generated 
by, and the private key is being safeguarded by, a device of so 
known tamper-resistant properties. In further embodiments 
of this invention, the chip may also have a hardware noise 
source, such as a diode noise source, to generate random 
numbers during key generation, and a unique physical 
device serial number to allow the device or its actions to be 55 
tracked in accounting, network management and inventory 
systems. In this embodiment, the device signature would 
certify not only that the user's device is of known tamper- 
resistant properties but also that every key or random 
number generated by the device was randomly generated 60 
anew each time using a high-quality random number 
generator, preferably a diode noise source. 

In manufacturing the trusted device containing the chip of 
the present invention, the chip's memory is divided into at 
least three general areas as follows: (1) permanent and 65 
non-modifiable memory space containing data and firmware 
embedded into the chip during manufacture; (2) semi- 



permanent and modifiable memory space containing data, 
such as the user's private encryption and signature keys, 
generated for the user and held in trust for the user by the 
chip, which data and keys may be utilized by the chip to 
make digital signatures or lo decrypt on the user's behalf but 
which are never disclosed outside the device; and (3) 
non-permanent and temporary memory space containing 
work area used for temporary storage of the inputs, inter- 
mediate results and final results of various data processing 
operations. Depending on the design, these three general 
areas could each reside in a different type of memory storage 
system, such as ROM for permanent data, EEPROM or 
FLASH memory for user data held in trust, and RAM for 
volatile temporary storage. Another approach might be to 
use FLASH memory for both permanent, and non- 
permanent data. Yet another option is to utilize a flip 
operating system that would manage the microprocessors 
memory using a directory of objects. Under this approach, 
one portion of memory can be devoted to a table or directory 
of the other items in memory and may include standardized 
information for each object, such as: 

logical name (e.g., "manufacturer's public key"); 

type (e.g., key, certificate, code routine, etc.); 

start address and length of data (in bytes); 

date last modified (optional); 

protection level (permanent, user or volatile); 

disclosure level (externally readable or not externally 
readable). 

In this manner, so long as the whole memory is equally 
temper-resistant, no special areas need be designated for 
protected or non-protected data because the microprocessor 
can readily enforce the desired level of protection based on 
the code contained in the relevant directory entry for the data 
object. This scheme can also apply to firmware code routines 
just as easily as to data, and may be advantageously applied 
when upgrading or replacing trusted firmware code routines 
without needing to physically replace the device or any of its 
memory units. 

The protected memory areas of a device of a preferred 
embodiment of the present invention might contain the 
following types of information, including both data and 
firmware program code. 

A. Permanently Embedded by Manufacturer 

1. May Be Externally Disclosed 

a. system-wide authority public key (optional) 

b. manufacturer public key 

c. manufacturer certificate from system-wide authority 

d. device public key 

e. device certificate from manufacturer 

f. device unique serial number 

g. firmware version numbers 

h. trusted bank public instruction keys 

2. May Not Be Externally Disclosed 
a. device private signature key 

3. Firmware 

a. operating system and file system 

b. basic cryptographic library routines 

c. escrow system routines 

d. other trusted applications code 

B. Generated by User Operations and Held in Trust for User 
1. May Be Externally Disclosed 

a. user's public encryption key 

b. user's public encryption key escrow certificate 

c. user's public signature key 
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d. user*s public signature key certificate 
2. May Not Be Externally Disclosed 

a. user's private decryption key 

b. user's private signature key 

C. Other Non-Volatile Read-Write Storage (Optional) 

a. correspondents' signature certificates 

b. correspondents* escrow certificates 

c. correspondents' device certificates (for MCH 
verification) 

D. Working Storage (Could Be Volatile) 

Public keys (all types), certificates (aJl types), hash 
values, signature blocks, other data structures being pro- 
cessed. 

Key Escrow Process 

After the chip of the present invention has been manu- 
factured and prior to using the chip to encrypt or decrypt 
communications, the user's public decryption key must be 
registered with a master escrow center or with escrow agents 
approved by the chip manufacturer. Either the user may 
perform this operation himself or the manufacturer may 
initialize and register the chip with an escrow agent during 
manufacture, thus relieving the user of the requirement to 
escrow his keys by himself. However, the manufacturer 
could still leave the user the option to rekey by himself at a 
later time. For many individual users, allowing the manu- 
facturer to register the chip, either with or without a rekey 
option, will be sufficient. In addition, consumers would most 
likely trust in the escrow agents chosen by the chip manu- 
facturer. Corporations or other employers could program 
their own chips and the chips of their employees, and could 
register the chips with escrow agents of their own choice. 
Corporations, however, would generally not permit their 
employees to rekey on their own, because this could result 
in loss of control over corporate information and assets, as 
discussed above. 

In order to generate and register a decryption key, the user 
(or whatever entity is performing the operation) invokes a 
firmware program that has been embedded into the chip and 
that instructs the chip to perform the particular steps of the 
MicaU key escrow method or of the specific key escrow 
method that is used. See FIGS. 9-11, 15 and 16. Using 
whichever method is chosen for escrowing the private key 
with one or more escrow agents, the chip will first randomly 
generate, or choose, a secret number that will be the private 
decryption key for that user (as well as the other, public 
numbers that will be required, if those numbers have not 
already been set by some other prior random generation). 
The chip will store the private key in a non-readable and 
tamper- resistant manner. As shown in FIG. 15, the private 
decryption key can be escrowed with a single escrow agent. 
The trusted device 150 first generates a public/private 
encryption key pair 151 for the user and then sends to the 
escrow center 153 an encrypted and signed message 152 
consisting of the encryption key pair 151 and the device 
serial number 154, with the manufacturer's certificate 155 
for signature verification. The escrow center 153 verifies the 
signatures, decrypts the message packet and stores the user's 
private decryption key. The escrow center 153 also sends to 
the user a signed certificate 156 consisting of the user's 
device serial number 154 and the user's public encryption 
key 151 and the device's public signature verification key 
157, with the escrow center's certificate 158 for signature 
verification. Once the user's device verifies the escrow 
center's signature, registration is complete. 

If the private key is to be escrowed with more than one 
escrow agent, then the chip will then break the private key 
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into several pieces called key splits, according to a specific 
formula. Using the Micali escrow method and algorithm 
described earlier and shown in FIG. 9, the chip will next 
compute certain values 90 using the special Micali algorithm 

5 such that each value is based upon a mathematical transfor- 
mation of one of the private key pieces 92. The chip then 
forms one share packet for each trustee or escrow agent 94 
designated by the user, each share packet 93 containing the 
unique serial number of the user's device, one private key 

10 split and the set of certain values that enable the particular 
trustee to verify the received private key split as a valid part 
of the complete private key, without giving the trustee 
knowledge of the complete private key. As discussed later, 
if the user is not the owner of the device but rather, for 

15 example, an employee of the employer-owner, the trustee 
share packet would also include the unique identification 
number of the owner of the device and the device's owner 
certificate so that employer-owner would be able to obtain 
the private key of the employee-user without having to first 

20 obtain a warrant. The chip then signs each trustee share 
packet using the unique device private signature key and 
attaches the manufacturer's certificate for the transmitting 
chip, thereby attesting that the information transmitted origi- 
nated from a device of known and trusted type. Finally, the 

25 chip will output each signed trustee share packet for deliver)' 
by the user to a trusted escrow agent. 

There is another, preferred way for the master escrow 
center to verify the separate key splits, without using the 
Micali method, by relying upon the trusted device alone. 

30 Using this method of verifying the key splits, shown in FIG. 
16, the chip generates one random number for each key split 
of the private encryption key. The chip then forms one share 
packet 161 for each trustee or escrow agent 163 designated 
by the user, each packet containing the unique number of the 

35 user's device, one private key spHt and one of the random 
numbers. The chip signs each trustee share packet using the 
unique device private signature key and attaches the manu- 
facturer's certificate 162 for the traasraitting chip, thereby 
attesting that the information transmitted originated from a 

40 device of known and trusted type. As with the Micali 
method, the chip will then output each signed trustee share 
packet 161 for delivery by the user to a trusted escrow agent 
163. In addition, the chip must also create a message 
(encrypted) 164 to the master escrow center 165 containing, 

45 among other things, the user's public encryption key and the 
names of the escrow agents designated by the user and along 
with the random number given with the key splits to each 
respective escrow agent. 

It is possible, however, because each trustee share packet 

50 contains a private key split, that a third party with access to 
communications from a user to the escrow agents could read 
the contents of all the user's share packets and recombine the 
private key splits within those packets in order to reassemble 
the complete private key. Then, using the private key, that 

55 third party could decrypt and encrypt communications in the 
name of the user. The best way to avoid this situation is by 
using encrypted communications systems when sending 
share packets from users to escrow agents. The user would 
obtain the public encryption key certificate 166 of each 

60 escrow agent selected for escrowing the user's private key, 
where each certificate is signed by the master escrow center 
certifying that the particular escrow agent is trusted by the 
master escrow center to receive and store a key split packet, 
and would then verify the master escrow center's signature 

65 either using a certificate from the device's manufacturer (or 
from a system-wide authority) or using a preembedded 
instructions key. The device woiild then encrypt for each 



08/28/2003, EAST Version: 1.04.0000 



5,850,451 

19 20 

escrow agenl based upon that agent's certified public systemwide trust, it might still be desirable to utilize a 

encryption key a transmission 161 that includes the user's verifiable key escrow algorithm such as the Micali process, 

private key share packet. Alternatively, the manufacturer it is clearly not necessary and may be dispensed with when 

could embed into the chip the public encryption keys of the added cost of using such a process cannot be justified. In 

several trusted escrow agents matched with an instructions 5 addition, by this method of relying upon the trusted device 

key for each, as discussed earlier, in order for the user to alone, there is no limit to the complexity of the key splitting 

send his private key splits to escrow agents trusted by the schemes that can be devised, because there is no need to 

holder of the instruction keys, which is typically the master devise complex secondary algorithms to verify correct per- 

escrow center. This way, all the escrow agents in the master formance of any given scheme. It is necessary only to trust 

escrow center's or the manufacturer's "family" could lO the integrity of the device manufacturer that embedded the 

decrypt user requests for escrow, while sparing the user the firmware code and to trust that the device will resist tam- 

burden of obtaining the public encryption key certificates of pering. 

all escrow agents. After verifying all the user's private key splits, the master 

Once each escrow agent or trustee 163 receives the escrow center itself further approves the public encryption 

appropriate share packet 161 from the user or from the user's 15 key that corresponds to the private decryption key that was 

device, the trustee inspects the private key split received in approved by all the user's trustees; the master escrow center 

the trustee share packet 161 from the user's device and, 165 approves the public key by issuing a signed certificate 

together with the master escrow center 165, verifies that it is 168 (called the master escrow center certificate, the pubfic 

a valid and correct part of the complete private key. It is encryption key certificate, or simply, the escrow certificate) 

necessary for the escrow agents and the master escrow 20 certifying that the private key corresponding to the public 

center to have a reliable means of proving or verifying that key being certified has already been escrowed in the proper 

the fragments of the user's private decryption key have in fashion. The public signature key of the user's device 

fact been deposited. It is desirable that verification of the key obtained from the device's manufacturer's certificate, can 

splits be accomplished by the escrow agents and the master also be placed in the master escrow center certificate, thus 

escrow center without ever inspecting or possessing those 25 eliminating the need to send or reverify the device manu- 

fragments itself, or ever bringing them together in one facturer certificate at later points in the process. The master 

location. The Micafi "Fair*' escrow system provides one escrow center certificate could be formatted as follows: 

highly trusted way for the escrow center to verify the Version Number 

separate deposits of the key fragments. In the Nficali ^^^^^ Certificate Serial Number 

method, shown m FIGS. 10 and 11, this verincation is done 30 ^ , ^ „ ^ ^ . 

with the set of certain valiies that were computed by the ^^^'^^ Escrow Center Country Code 

user's chip during preparation of the share packet through Master Escrow Center Name 

use of a special Micali algorithm and that were included with Master Escrow Center Public Encryption Key (for use in 

the key split in each share packet to the escrow agents. The creating LEAF) 

Micali algorithm and key spHt verification are known in the 35 User Distinguished Name 

art and need not be repeated here. Each trtistee 94 then stores ^j^^ j^^jj^ Encryption Key (hereby being certified) 

the devices manufacturers certificate for later use m . ru.i. o- . \r -c ^- v u c 

, J. J ^,1 1* ni u J- User Device Public Signature Verification Key (to verify 

decodmg, and approves the key split 93 by sending an device si nature^ ^ \ ^ 

appropriate signed message 96 to the master escrow center, evice sign e; 

along with the user's name and device certificate and by 40 Validity Date (start/end) 

signing and storing the key split 90, only when presented Master Escrow Center Signature 

with either (a) a warrant or court order or (b) a signed request [Master Escrow Center System- wide Certificate] 

from the lawful owner of the device will the trustee reveal Public encryption key certificates that have been issued by 

the piece (or pieces) of a given private decryption key in its the master escrow center are distributed and can be used 

possession. 45 either by the device owner in order to activate his device to 

Using the preferred escrow and verification method rely- originate encrypted messages or by others to encrypt mes- 

ing on the trusted device alone, shown in FIG. 16, each sages to the owner of the device containing that user's 

trustee 163 transmits a message 167 to the master escrow pubUc/private encryption key pair. 

center 165 identifying the user's name, pubhc encryption It should be noted that the present invention docs not 

key, device number and the random number it received. In 50 require more than one escrow agent to be the recipient of the 

addition, the user device sends a packet to the master escrow user's private encryption key spUts; in some cases, it might 

center 165 containing the random numbers used for verifi- be enough merely to deposit the user's private decryption 

cation of the private key spUts, and that packet should be key with a single escrow agent (or escrow center). However, 

encrypted using the master escrow center's public encryp- in order to enhance user and public trust in the system, it is 

tion key. The master escrow center 165 receives the mes- ss desirable to split the user's private decryption key among 

sages 164,167 from the user device and from the trustees several escrow agents such that all the key splits, or some 

163, and verifies that the individual random number specified number of them, are required in order to reas- 

rcceived from each trustee matches the random number that semble the user's key and decrypt his communications. It is 

the user device stated was given to that trustee. Note that further desirable that each escrow agent be an independent, 

under this method the escrow agents 163 and master escrow 60 trusted business operation, thereby effecting "split 

center 165 rely solely upon the trusted device's signature on knowledge," so that in the event of attempted corruption, 

the share packets 161 to assure themselves that the escrow bribery, extortion or abuse, it will be much more difficult to 

is proper. This escrow and verification method does not need wrongfully obtain the user's private decryption key than it 

to perform any secondary mathematical operations in order would be if the private key were stored with a single entity, 

to verify that the escrow is proper or that the public key 65 It is also desirable that the entities be separated geographi- 

presented for certification matches the deposited key frag- cally in order to further suppress attempted subversion or 

ments. Although from the standpoint of public, user or corruption. 
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Encryption of Communications 

A user who desires to send an encrypted communication 
to another user must have an escrow certificate for his own 
device and an escrow certificate for the intended recipient's 
public encryption key, because the device of the present 
invention will neither encrypt nor decrypt if either is miss- 
ing. First, the sender must load his own valid certificate into 
the device, typically when he first receives it from the master 
escrow center. Then, the intended recipient's public key 
certificate can be obtained cither from the intended recipient 
directly, from a directory service listing public key 
certificates, or from the sender's local file, e.g. a file of users 
with whom the sender has previously exchanged encrypted 
communications. In one embodiment of the present 
invention, because the sender's device will not encrypt and 
the recipient's device will not decrypt unless the recipient's 
public encryption key certificate is 'Valid,'* in order for the 
recipient's device to decrypt the encrypted message, the 
recipient's public encryption key certificate must be signed 
by either (a) the recipient device's manufacturer (this is 
unlikely to be the case because device manufacturers will 
most probably not be escrowing user's private keys); (b) the 
master escrow center, and accompanied by a manufacturer's 
certificate approving the master escrow center as a valid 
trustee; or (c) a trustee or master escrow center whose 
instructions key was embedded into the device during manu- 
facture. Using the intended recipient's certified public 
encryption key as set forth in the recipient's public encryp- 
tion key certificate, the sending user then generates a session 
key for use by both the sender and the recipient to encrypt 
and decrypt the communication. This session key can be 
generated preferably using the Certified Diffie-Hellman 
method or, alternatively, any other equivalent system. In the 
Certified Diffie-Hellman method, the user first randomly 
generates his ephemeral private key for that message and 
then computes the session key based upon his own private 
key and the recipient's public key (i.e., the recipient's 
intermediate number and the two public numbers, which are 
all contained with the recipient's public encryption key 
certificate). Then, using the session key, the sender encrypts 
the message to be sent to the recipient user. 

However, in deciding whether or not to send an encrypted 
message to the intended recipient, the sender may be unable 
to verify the properties of the recipient's public encryption 
key certificate or of the digital signatures thereon if the 
sender's device were made by a manufacturer different from 
the one that made the recipient's device. The fact that the 
recipient's device was made by a different manufacturer 
would prevent the sender's device from easily verifying 
either the manufacturer's signature or the certificate of the 
manufacturer (that certified the master escrow center that 
signed the recipient's key escrow certificate) stating that the 
recipient's master escrow center is valid and approved by 
that manufacturer. Likewise, the recipient's chip would be 
unable to verify these conditions with respect to the sender's 
certificate before decrypting. Enforcement of the escrow 
restriction on both parties is needed in order to enable law 
enforcement agents to lawfully intercept and decrypt mes- 
sages being both sent and received by a given suspected 
user, without necessarily obtaining the other, non-monitored 
party's private decryption key and, thereby, access that 
non-monitored party's unrelated messages. 

One way to address this issue, while still allowing more 
than one manufacturer to make cryptographic devices, is to 
embed into the device or into a certificate issued by either 
the user's master escrow center or the chip manufacturer a 
public key from a trusted national entity, for example the 
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Federal Reserve Bank ("FRB"), which could be used to 
verify yet another certificate issued by the FRB to each of 
the other various master escrow centers or manufacturers. 
Such a certificate would verify the trustworthiness of the 

S particular master escrow center or manufacturer and would 
be signed by the FRB. A sending user could then obtain the 
public encryption key certificate of an intended recipient and 
could trust the master escrow center that issued the certifi- 
cate because the master escrow center was accredited by the 
FRB, rather than by the chip manufacturer, as certified by the 
FRB public key or certificate. Also, the signature of a 
particular device could be trusted because the other manu- 
facturer that certified that device was accredited by the FRB, 
as certified by the FRB certificate or public key. In order to 
deal with this issue on a less parochial United States based 

15 level and promote a more international and worldwide 
system, the public key of a trusted global entity, such as the 
Bank for International Settlements in Switzerland, could be 
embedded into either the trusted device, the FRB certificate 
or the master escrow center or manufacturer certificate 

20 (depending upon the trust model employed), and could 
operate the same way discussed regarding the FRB key, in 
order to accredit master escrow centers and manufacturers 
on a worldwide basis. Another way, albeit one not involving 
U.S. or world authorities, for one device to trust the escrow 

25 centers certified by another manufacturer is for the device 
manufacturers or master escrow centers to cross-certify each 
other. This would allow the sender's device to help enforce 
the recipient's escrow restrictions by allowing the sender's 
device to verify the certification path of the recipient's 
escrow certificate back through the recipient's device manu- 
facturer or master escrow center to his own. In the preferred 
embodiment, the public key of a trusted system-wide entity 
would be embedded into the trusted device and would 
operate the same way discussed above regarding the FRB or 
global entity key, in order to accredit all the master escrow 

^5 centers and manufacturers on a system-wide basis. 

Whenever any user, entity or device "verifies" a digitally 
signed "certificate," whether a manufacturer's certificate or 
an escrow certificate, issued by a certifying authority or 
manufacturer, it is common practice in most or all actual and 

40 proposed public key certificate management systems (and it 
is assumed throughout this disclosure) that the user, entity or 
device also checks any applicable "certificate revocation 
list" ("CRL") in order to determine whether the certifying 
authority or other issuer has distributed, propagated or 

45 otherwise made available a list of revoked certificates that is 
updated in accord with an appropriate security policy and 
whether, based upon the issuer name and certificate number, 
the certificate has been revoked. A certificate issued to a user 
could be revoked for death, name or employment change, or 

50 loss, theft or desU-uction of the device (the personal smart 
card) containing the private key. A certificate issued to an 
entity may be revoked due to cessation of business, name 
change, or loss, theft or destruction of the device containing 
the private key. A certificate issued to a device may be 

55 revoked due to loss, theft, removal from service or destruc- 
tion of the device. The checking of CRLs during certificate 
verification is well-described in the public literature (e.g., 
ANSI X9.30 - Part 3) and does not require further discus- 
sion. All users, entities and devices will normally have 

60 access to appropriate telecommunications facilities and can 
retrieve CRLs or perform inquiries as desired. Likewise, 
under the present invention, all entities Issuing CRLs are 
presumed to make them available to all interested parties. 
Message Control Header Format 

65 When sending an encrypted communication, the sending 
user must also form a suitable Message Control Header 
(MCH) field containing the following information: 
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(1) The sender's intermediate number for the encrypted between the two parties. The certificate could also be a 
message, computed by the sender using the sender's ran- cross-certificate from the recipient's manufacturer or master 
domly generated ephemeral private key that was also used escrow center. 

by the sender to compute the session key with which the The MCH thus described could be summarized as fol- 

message was encrypted. The recipient user must have this 5 lows: 

intermediate number in order to compute the session key for Sender Intermediate Number (to allow the recipient to 

decrypting the message. decrypt the message) 

(2) The name and country code of the sender's master g^^^^, faster Escrow Center Country Code 
escrow center. r, . ^ 

(3) The name and country code of the recipient's master lO lender Master Escrow Center Name 

escrow center, obtained from the recipient's public key Recipient Master Escrow Center Country Code 

certificate. Recipient Master Escrow Center Name 

(4) The sender's escrow certificate number, encrypted Sender Escrow Ceraflcate Number, encrypted for Sender 
using the public encryption key of the sender's master Master Escrow Center 

escrow center (obtained from the sender's escrow is ^^^^^ Intemediate Number (for encrypting the sender 

certmcate) so that only the sender s master escrow center certificate number) 

may decrypt it. . , ^ . , ^ , 

(5) -nie sender's intermediate number (different from the ^^'^^^ ^^^^^^ ^^V' encrypted for sender 

sender's previous intermediate number) that was used by the Sender Intermediate Number (for encrypting the message 

sender to compute the ephemeral session key with which the 20 session key to the sender) 

sender's certificate number was encrypted to the sender's Recipient Escrow Certificate Number, encrypted for 

master escrow center. The sender's master escrow center Recipient Master Escrow Center 

must have this number in onJer to compute the ephemeral Sender Intermediate Number (for encrypting the recipient 

key for decrypting the sender's certificate number. certificate number) 

(6) The session key for the encrypted message, encrypted 25 TiraestamD 

using the sender's own public key (the intermediate number „ , ^ . ^ „. 

from the sender's own public certificate), so that in effect the ^^""^^ ^""'''^ MCH Signature 

sender sends the message session key to himself. Law [Sender Escrow Certificate] 

enforcement can gain access to this message session key [Escrow Center Certificate] 

once it obtains the sender's private key components from the 30 FIG. 17 shows a process for sending an encrypted message 

sender's escrow agents. 176 with a MCH. The entire MCH 172 (the appended 

(7) The sender's intermediate number (different from the certificates 173,174,175 are not technically part of the 
sender's two previous intermediate numbers) that was used MCH) is signed by the sender's device 171, using the device 
by the sender to compute the ephemeral key with which the private DSA signature key, with the embedded certificate of 
message session key was encrypted to himself. Law enforce- 35 the manufacturer appended thereto (within the sender's 
ment must have this number in order to compute, using also escrow certificate) in order to certify the device's public 
the sender's private key (his secret number) obtained from signature key. This guarantees that the entire MCH is 
the sender's master escrow center, the ephemeral key for delivered intact to the recipient and that the recipient's chip 
decrypting the message session key. can easily verify that the MCH has not been modified. The 

(8) The recipient's certificate number, encrypted using the 40 manufacturer's certificate might be accompanied by an 
public encryption key of the recipient's master escrow national (FRB) or a world-authority certificate to certify the 
center (obtained from the recipient's escrow certificate) so trustworthiness of the manufacturer of the sender's chip in 
that only the recipient's master escrow center may decrypt case the recipient's device was manufactured by a different 
it. manufacturer. 

(9) The sender's intermediate number (different from the 45 In another embodiment of this invention, a second, shorter 
sender's three previous intermediate numbers) that was used MCH format could be used for the case in which total 
by the sender to compute the ephemeral key with which the privacy is not crucial. In this MCH, neither the Sender 
recipient's escrow certificate number was encrypted to the Certificate Number nor the Recipient Certificate Number are 
recipient's master escrow center. The recipient's master encrypted for the respective master escrow center. Not 
escrow center must have this number in order to compute the 50 encrypting the certificate numbers saves much time and 
ephemeral session key for decrypting the recipient's certifi- space in creation of the MCH. In still another embodiment 
cate number. of this invention, a third, even shorter MCH format could be 

(10) Timestamp (optional), for tracking purposes and used for the common case in which the sender and the 
possibly to assist ii3 the enforcement of warrant date and recipient both utilize the same master escrow center for key 
time restrictions. ss escrow purposes, by making ECl identical to EC2. By 

(11) The signature of the sender's device. eliminating the need in the MCH for identifying information 

(12) The sender's public key escrow certificate issued by of the second master escrow center and for the special 
the sender's master escrow center. The sender's escrow intermediate number that is used for encrypting the recipient 
certificate contains the sender's device public signature key, certificate number to the second master escrow center, the 
which the master escrow center had pre -verified and then 60 MCH can be made significantly shorter. Furthermore, the 
copied from the sender's device's manufacturer's certificate. .size of the MCH could be further reduced by using RSAkey 

(13) The master e.scrow center's certificate from the FRB, transport to encrypt a DES key for the message and for each 
the manufacturer or whatever system -wide authority is of the three encrypted inner LEAF components. According 
trusted, if the recipient's chip is made by a different to this method, each sender intermediate number would be 
manufacturer, appended to the sender's escrow certificate. 65 replaced by a smaller RSA-wrapped DES key. Thus, the 
The certificate of the manufacturer, the FRB or the system- sender could RSA-encrypt the message session key for the 
wide authority is needed only for the first communication recipient and eliminate the need for the first intermediate 
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number in the MCH. The sender could also RSA-encrypi the secret number occur inside the would-be recipient's device, 
message session key for himself (actually, for law enforce- that this new secret number remain inside the trusted device, 
ment to decrypt later) and thus eliminate the need for the and that the new intermediate number be signed by the 
third intermediate number in the MCH. The sender could would-be recipient's device prior to being sent to the send- 
further RSA-encrypt his own and the recipient's certificate 5 er's device for the purpose of attesting that the new ephem- 
numbcrs and thus eliminate the need for the second and cral secret number is indeed confined securely inside the 
fourth intermediate numbers in the MCH. As shown in FIG. recipient's device. As before, the sender's device generates 
18, eliminating the four intermediate numbers and its asso- a new secret number that is separate and apart from the 
ciated encryption and replacing each intermediate number sender's escrowed private key and, using that new secret 
with a smaller RSA transport encryption 181 saves a sig- lo number and the recipient's new intermediate number, gen- 
nificant amount of space of the MCH size. erates the message session key for decrypting the message. 
Contribution of Random Material The sender's device will also use the sender's new secret 
Some may be concerned that a message session key number to generate the sender's new intermediate number, 
exchanged using only the RSA key transport method or the which will be sent to the recipient's device as an element of 
Certified Dififie-Hellman scheme is not sufiBciently secure 15 the MCH for wiretapping purposes. In this method, the 
because, with either of these two methods, although both the message session key would, therefore, include random mate- 
sender and the recipient provide information, only the rial contributed by both the sender and the recipient, as 
sender generates the message session key. However, under desired. 

military standards for secure communication, both sender However, under this modified key-exchange protocol, 

and recipient m\ist contribute random material in generating 20 because the recipient and sender in effect use new Dififie- 

a session key prior to each communication session, appar- Hellman private keys for each message, the escrow feature 

ently in order to reduce the chance that the sender might use still ''disappears " as law enforcement and corporate man- 

a weak key or use the same key repeatedly and thereby agement would never be able to obtain those ephemeral 

subject the recipient to an undesired security risk against his message session keys from the escrow agents. Therefore, the 

will. The system of trusted devices contemplated under this 25 needs of the escrow system and the community of interest 

invention can alleviate this fear in two ways. First, it can require that the message session key be transported in the 

ensure that the sending device will generate each key MCH as before. In fact, in order to assure equality of 

separately using random numbers derived from the noise of tapping, all fields that were before disclosed as part of the 

a built-in hardware noise source, such as a reverse -bias MCH remain so. The field transporting the message session 

diode, as discussed earlier. Then, so long as the device signs 30 key to the sender (which is the only way for law enforcement 

the MCH or message control header, the recipient would be agents who are wiretapping the sender to read the message) 

assured that each message session key and the random must still be included in the MCH in order to preserve the 

numbers used in generating it are strong and unique, StUl, principle of equality of tapping. The message session key 

those insistent upon greater security may demand contribu- will be encrypted into the MCH, as before, using the 

tion of random material by both sides of the communication, 35 sender's public encryption key, to which law enforcement 

as defined for Type-1 military systems for classified infor- will still have access. The sender's new intermediate number 

mation. will be sent to the recipient as the first element of the MCH, 

Thus far in this disclosure, the sender has been described as before, in order to allow law enforcement to wiretap the 

as generating message session keys based on the recipient's recipient and compute the message session key. Thus, in 

public encryption key as contained in his escrow certificate, 40 order to accommodate the Interactive Diffie-Hellman key 

but not based on random material received from the recipi- exchange technique, this protocol requires that the would-be 

ent during the setup phase of the communication. Arranging recipient's new intermediate number be generated inside and 

for the sender to receive a contribution from the recipient, be signed by his device, and requires that the sender's new 

however, creates a new problem. The recipient cannot intermediate number be added to the MCH, not used in place 

simply be allowed to generate a Difi&e -Hellman intermediate 45 of the previously stated key transport methods, as that is the 

number on his own and send it to the sender for use in only way the community of interest (law enforcement, 

generating a message session key, because the recipient then employers, and others) can read the message. This method, 

would no longer be using the escrowed private key within however, would not be economical for transactions besides 

his trusted device to decrypt messages and because their on-line phone, network, or dial-up transactions, because the 

communications could never be monitored by law enforce- 50 device would have to remember too much, i.e. the special 

ment. Continued success in enforcing the escrow scheme intermediate numbers for each counterparty. This method is 

requires that neither sender nor recipient be able to read a preferably to be used in cellular phone, network logons, etc., 

message without using a registered trusted device. through which a purely real-time interactive session is 

In order to allow a situation in which both the sender and desired, 

the recipient contribute random material to the message 55 Community of Interest Headers 

session key prior to communicating, the initial key- The MCH will generally be placed before the encrypted 

exchange protocol may be modified to allow a would-be message, as a message header. In many current electronic 

recipient's device to generate a new ephemeral DifBe- mail and document systems, several recipients arc enabled 

Hellman secret number, separate and apart from that recipi- to read one encoded message, using the RSA transport 

cnt's escrowed private key, that will be used to compute a 60 embodiment of the MCH design as discussed above, by 

new intermediate number that will, in turn, be sent to the RSA-encrypting the message .session key using the public 

sender for use computing the message session key for encryption key of each recipient. That is, when several 

encrypting the message. The recipient's escrowed private recipients are intended to receive the same encrypted 

key would stni be used to generate the intermediate numbers message, the MCH header can include, for each intended 

(included in the MCH) and the ephemeral session keys that 65 recipient, the intended recipient's name followed by the 

are used to encrypt the various portions of the MCH. This message session key, RSA-encrypted to each intended 

modification requires, however, that generation of the new recipient using that recipient's public encryption key. Thus, 



08/28/2003, EAST Version: 1.04.0000 



5,850, 

27 

each intended recipient can locate his entry in the MCH 
header, decrypt his copy of the message session key and read 
the message. Even with several intended recipients, the 
correctness of the MCH is enforced on both ends of the 
communication: on the sending end, the MCH output is s 
enforced by the internal logic of the sender's device, i.e. the 
requirement that it create a valid MCH prior to encrypting a 
message; on the receiving end, the MCH correctness is 
enforced by verification by the receiver's device of the 
digital signature of the sender's device. As previously noted, lo 
because the recipients' copies of the message key are 
integral to the MCH, no recipient can decrypt the message 
unless the MCH is sent and received intact, unlike the 
Clipper system in which the MCH is not itself linked to the 
key transport mechanism. 15 

Under this MCH formatting concept, the MCH could be 
summarized as shown in FIG. 25. As in previous MCH 
formats, the authenticity of the MCH is guaranteed by the 
digital signature of the sender's device 258. Furthermore, as 
before, the escrow certificate numbers of the sender and the 20 
recipient are encrypted under the public encryption keys of 
their respective master escrow centers 251,252. In this 
format, however, the MCH, signed by the sender's device, 
becomes a modified "list of recipients" that is more flexible 
and easier to understand in relation to the way contemporary 25 
encrypted electronic mail systems work. For example, the 
sender's and recipient's names (or system IDs or addresses) 
are now shown unencrypted in the MCH 253,254. Although 
this impinges on the anonymity of the sender and the 
recipient, as a practical matter it is difficult to send messages 30 
in an electronic mail system without tagging the messages 
with the names and addresses of the senders and recipients. 
Hence the loss of privacy is slight. In addition, the names of 
the sender's and recipient's employers 255,256 (or their 
unique IDs, such as tax numbers or DUNS numbers) are also 35 
shown unencrypted, thus greatly reducing the burden on the 
employers' security staffs to find messages sent and received 
by their respective employees. Alternatively, instead of 
leaving the sender, recipient and employer name blocks 
unencrypted, these entries could just as well read ''sender," 4Q 
"addressee," "sender's employer" and "recipient's 
employer" (or their equivalents) unencrypted, with the 
actual identifiers inside the encrypted areas, as before. Thus, 
an intended recipient of the communication would look in 
the MCH for his unencrypted identifying abbreviation and in 45 
this way will attempt to decrypt and read only the portions 
of the MCH that are directed to and encrypted for him. 

In addition, this MCH format as shown in FIG. 25 allows 
access by possible sub-units within the employer 
organization, by defining secondary employer lines (a, b, 50 
etc.). For secrecy -conscious employers, the MCH could read 
"sender empl sub-unit b" unencrypted, as discussed above, 
and contain the actual company unit identifier in the 
encrypted area. Because each MCH entry is labeled, there is 
no limit on how many layers of employer access there can 55 
be; all of them become in some sense authorized "recipi- 
ents" of the message. Furthermore, in contrast to previous 
MCH formats, this MCH format can include the message 
session key encrypted directly to the employer 257 so that 
the employer need not go to the master escrow center and 60 
agents in order to obtain the message session key for 
decrypting the message. Although possibly impinging on 
employee expectations of privacy in the workplace, this 
format can allow employers to check or recover their 
employees' files with minimal effort. 65 

In order to create a MCH in this format prior to sending 
a communication, the sender must first obtain all the nec- 
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essary names/codes and public keys of the intended recipi- 
ents and their employers. This information can be garnered 
from the recipient's escrow certificate and from his own 
escrow certificate. However, in order to generalize this 
approach and make this information available to a user who 
desires to send a commxmication, the master escrow centers 
must include into each user's standard form escrow 
certificate, as discussed earlier, the unique identification or 
code number and public encryption key of both his employer 
and any employer sub-units. The escrow certificate layout 
could be designed by using repeating subgroups, for efficient 
handling of variable numbers of "community-of-interest" 
parties. Each community-of-interest party entry would have 
a unique identification number, a public encryption key and, 
possibly, an instruction code (or policy code, as discussed 
below) instructing the sender's device how to encode that 
party's MCH entry. The instruction code could include 
elements of choice giving the sending device the options of 
including (1) the party's unique identification number cither 
unencrypted or using an alias, e.g. "empl-a;" (2) the message 
session key in the coded area or not; (3) the party's unique 
identification number in the coded area or not; and (4) the 
timestamp or a random number at the start of the coded area 
or not. These (and possibly other) instruction codes could be 
defined as bitmask flags. The list of parties (and/or their 
codes), their public encryption keys and the instruction flags 
would tell the sender's device how to format the 
community-of-interest portions of the MCH in accord with 
the desires of each party for partial or total anonymity. It is 
anticipated that in practice, many community-of-interest 
parties will not bother with anonymity, because it will be 
much easier for them to search for and identify their employ- 
ees' messages if they keep their own names and identifica- 
tion nimibers in the clear. 
Decryption by Recipients 

When the intended recipient receives the encrypted mes- 
sage 191 and the MCH field 192, several things must be 
done in order for the recipient to read the message, as shown 
in FIG. 19. First, the recipient must load his own valid 
escrow certificate 193 into his chip 190 because, under the 
preferred embodiment of this invention, the chip will not 
decrypt without it. Typically, the recipient's escrow certifi- 
cate will already be stored in the device's memory in a 
pre-verified state. The recipient next loads the MCH 192 and 
the sender's escrow certificate 194, which also contains the 
sender's device's public signature verification key (with the 
appropriate system-wide, national or world authority certifi- 
cate 195, if necessary) into his chip 190. The recipient's chip 
190 checks the sender's escrow certificate 194 in order to 
verify that the sender's private decryption key has been 
escrowed. This is done by using the public key of the 
manufacturer to verify the signature of the manufacturer on 
the device certificate or, if necessary, the signature of the 
system-wide authority on the escrow center certificate and 
by checking whether the escrow center's signature on the 
sender's escrow certificate is valid. In the preferred 
embodiment, the public signature key 196 of the system - 
wide authority is used to directly verify the escrow certifi- 
cate 195. The recipient's chip then checks the MCH signa- 
ture before proceeding in order to verify that (1) the sending 
device is trusted, (2) the sender's key is escrowed, as also 
verified by the sender, and (3) the MCH 192 is valid, i.e. the 
MCH is in the proper format and contains all the requisite 
information. This is done by verifying the sender's device 
signature, the sender's device manufacturer's certificate 
signature and, if necessary, the manufacturer's system-wide 
authority certificate. The manufacturer's and the system- 
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wide authority's public keys could be embedded into the the sender into the MCH as a message sent to himself. The 

recipient's chip 190 to facilitate this verification process. In decoder box can then monitor and intercept communications 

the simplest case, the recipient need validate the sender's to and from the sender only during the monitoring period 

escrow certificate 194 only once, against its own embedded specified in the warrant, and can continue to decrypt those 

manufacturer's public key or system-wide trusted entity S intercepted communications only until the end of the grace 

instructions key. Once those are shown to be valid for a period specified in the warrant. 

particular sender, the recipient needs only to use the sender's A similar procedure is used to monitor commuQicalions to 

pre-validated device public key to validate the MCH and from the recipient. From the MCH of the intercepted 

signature, resulting in only a single signature validation per communication, law enforcement identifies the name and 

message. If either the sender's certificate 194 or the MCH lO country of the recipient's master escrow center and then 

192 is invalid, the recipient's chip will not decrypt the presents the warrant and the MCH from the intercepted 

message. Finally, after verifying these certificates and communication to the recipient's master escrow center, 

signatures, the recipient computes the message session key which uses its private key to decrypt the recipient's certifi- 

based upon the sender's intermediate number, which was ^ate number that was encrypted into the MCH. Using the 

included in the MCH, and the recipient's own private key is recipient's certificate number, the recipient's master escrow 

(his secret number) corresponding to his pubUc key as center looks up the recipient's name and the names of his 

publicized in his pubhc encryption key certificate 193. escrow agents and reveals them all to the law enforcement 

Using the session key, the recipient decrypts the message agent. The law enforcement agent then contacts each of the 

sent by the sending user. recipient's escrow agents and presents to it the recipient's 

Decryption by Law Enforcement 20 name and the warrant. Each escrow agent sends the key split 

In order to intercept and decrypt communications to and entrusted to it by the recipient user to the law enforcement 

from a particular user, law enforcement must have court decoder box as a message encrypted to the decoder box 

authorization or a warrant to monitor that particular user's having a *'start monitoring" date, a "stop monitoring" date 

communications. The court authorization will, in all and a grace period for enforcement of the terms of the 

probability, include (1) a ''start monitoring" date and time at 25 warrant by the decoder box. The decoder box then decrypts 

which law enforcement may begin to monitor the user's t^e encrypted key splits, combines them and uses the recipi- 

communications, (2) an "end monitoring" date and time ent's resulting reassembled private key, along with the 

after which law enforcement may not monitor the user's sender's intermediate number, which is at the head of each 

communications, and possibly (3) a grace period to follow mCH, to compute the session key for the communication, 

the "end monitoring" date, during which grace period the 30 xhe decoder box can then monitor and intercept communi- 

law enforcement may retain the user's private key in order cations to and from the recipient only during the monitoring 

only to decrypt the previously-intercepted communications period specified in the warrant, and can continue to decrypt 

but not to intercept or monitor any additional communica- those intercepted communications only until the end of the 

tions of that user. In monitoring the communications of the grace period specified in the warrant, 

sending user, law enforcement intercepts the communication 35 another embodiment of the present invention, the 

and identifies from the MCH the name and country of the format for each escrow agent's encrypted key split message 

sender's master escrow center in order to determine from to the law enforcement decoder box might be as follows: 

whom to request the sender's private decryption key. Law User's Certificate Number 

enforcement then presents the court authorization and the d ■ t v c t v/'*\ 

MCH from the intercepted communication to the sender's 40 ^'"^^^^^ hragment: X(i} 

master escrow center, which uses its private key to decrypt Begin Monitoring Date and Time 

the sender's certificate number that was encrypted into the Stop Monitoring Dale and Time 

MCH. Using the sender's certificate number, the sender's Court-allowed Grace Period (days/hours) 

master escrow center looks up the sending user's name and j^^^^ j^^^ . ^ ^^^-^ message) 

the names of the sender's escrow agents, and reveals them as 

all to the law enforcement agent along with the sender's Escrow Agent Signature 

device manufacturer certificate, which law enforcement will [Escrow Agent Certificate] 

need later during decoding, llie law enforcement agent then In this format, all information except for the Certificate 
contacts each of the sender's escrow agents and presents to Number would be encrypted under the encryption key of the 
it the sender's name and the warrant, and obtains from each 50 decoder box. Because the key spUt messages from the 
escrow agent the key splits entrusted to it by the sender. escrow agents are encrypted for that particular decoder box, 
Because the preferred method of intercepting and decrypting no other user or decoder box can read them. Furthermore, 
encrypted communications by law enforcement in this the "Begin Monitoring" and "Stop Monitoring" dates and 
invention is by using the decoder box specified below, the times instmct the decoder box when to begin monitoring and 
law enforcement request to the escrow agents will also S5 decoding communications and when to stop monitoring; the 
include the public encryption key of the law enforcement Grace Period allows the decoder boxan additional, specified 
decoder box, so that the key splits can be sent directly to the time period to decode any backlog of the previously inter- 
law enforcement decoder box and not to the law enforce- ccpted communications, after which time period the decoder 
ment agents themselves. Each escrow agent sends the send- box must stop decoding and must erase the subject's private 
er's key split in its possession to the law enforcement 60 key. Thus, the decoder box can be used to decrypt the 
decoder box as an encrypted message having a "start moni- monitored user's communications until the date specified in 
toring" date, an "stop monitoring" date and an optional the warrant, at which time the decoder box and its embedded 
"grace period" so that the decoder box can enforce the terms time clock prevent any further decryption. The decoder box 
of the warrant. The decoder box then decrypts the encrypted could also refuse to process key split messages having a 
key split messages, combines the key splits and uses the 65 Message Date and Time older than twelve (12) hours (or 
sender's reassembled private key to obtain the session key some other specified time period) or having an Expire Date 
for the communication, which session key was encrypted by and Time that has already passed. 
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Decoder Box Implemenlation 

In a preferred embodiment of this invention, law enforce- 
ment employs a special tamper-resistant decoder box for 
intercepting and decrypting the communications of moni- 
tored users under certain defined and controlled conditions. 
An example of a decoder box and its process flow is shown 
in FIG. 20. The decoder box 200 is designed to be a trusted 
device of a similar design within the system of trusted 
devices of the present invention and, therefore, can enforce 
various conditions in order to prevent improper action by 
law enforcement agents. The decoder box 200 has a private 
device signature key embedded by the manufacturer and a 
manufacturer's public signature key certificate 202 for the 
public signanire key that matches the device private signa- 
ture key. In addition to the manufacturer's certificate 202, 
the decoder box may also have a certificate 203 issued by (or 
on behalf of) a law enforcement authority or corporate 
security department that owns the decoder box, attesting or 
notarizing the connection between the decoder box and the 
law enforcement or security authority, and attesting that the 
decoder box Ls under its sole possession and control. The 
decoder box 200 also has the ability to generate a public/ 
private key pair, just like the regular user chip of the present 
invention, for encryption and decryption of administration 
and control messages to the decoder box. The decoder box 
200 further has the abiUties to store its private key securely 
and to issue the corresponding public encryption key within 
a certificate 201 signed by itself, with its device certificate 
202 signed by the manufacturer attached. Having this ability 
to generate (and use) the public/private key pair enables the 
escrow agents 206 of a wiretapped user, upon presentation 
by law enforcement agents to the master escrow center of a 
warrant to monitor the user's comnaunications, to send the 
key splits 204 of that wiretapped user to the decoder box 
encrypted using the decoder box's public encryption key and 
enables the decoder box to decrypt those key splits using its 
private decryption key. However, unlike a regular user chip 
of the present invention, which decrypts a message and 
returns the unencrypted result to the user, the decoder box 
never outputs the wiretapped user's private key to the law 
enforcement agents. Instead, the decoder box stores this 
information securely until the end of the Grace Period 
specified in the warrant and in the key split messages, at 
which time the decoder box erases the information perma- 
nently. 

Accordingly, in order to perform its duties as a trusted 
device and enforce the date and time restrictions imposed by 
the wiretap authorization, the decoder box 200 must also 
contain a trusted, calibrated and certified date/time clock 
205. The decoder box manufacturer certifies and attests to 
the validity and the calibration of the clock 205 when the 
manufacturer issues a device certificate 202 with its list of 
known device properties. When the decoder box 200 
receives from the escrow agents 207 the key splits 204 
containing time limits (based upon the warrant) before or 
after which the warrant is not valid, the decoder box 200 
uses its internal time clock 205 to verify that the law 
enforcement warrant is still valid. If the warrant is not yet 
valid, the decoder box will not monitor or decrypt the 
communications of the wiretapped user. If the warrant (and 
any applicable grace period) has expired, the wiretapped 
user's private key is erased and will not be recreated again 
under that warrant by the decoder box (unless a new warrant 
having a new time period is issued). It should be noted that, 
although the trusted time clock 205 is optional for a regular 
user chip of the present invention, it is mandatory for the 
decoder box 200 in order to allow the decoder box to enforce 
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the date and time limits of the wiretap warrant. However, the 
user of the regular user chip can assist in the time limit 
enforcement by maintaining tlie calibration of his chip's 
lime clock. If the user's clock is not cahbrated, the MCH 

5 generated by the user's device during communications will 
contain a null value in the timestamp field. In that case, the 
decoder box intercepting the communication will be able to 
enforce only the Stop Monitoring Date of the warrant by 
refusing to decrypt after the expiration of the warrant and 
grace periods. Then, the decoder box cannot enforce the 
Begin Monitoring Date because, as long as the warrant is 
still valid, the warrant allows decrypting of all MCHs 
submitted with null timestamp values even if they were 
intercepted prior to the warrant period Begin Monitoring 
Date and Time. But, if the user's clock is calibrated, the law 

^5 enforcement decoder box can and wiU refuse to decrypt all 
MCHs containing a valid and trusted timestamp for a date 
and time prior to the warrant Begin Monitoring Date and 
Time. Most preferably, the decoder box of the present 
invention will decrypt only communications that arc reliably 

20 timestamped during the warrant time periods. It is antici- 
pated that this added immunity from potential abuse of 
wanant time periods by law enforcement may motivate 
users of the chip of this invention to maintain their chips in 
a cahbrated state. Indeed, where the system is used to 

25 encrypt large numbers of messages in a data storage system, 
the enforcement of time periods for a later warrant or 
discovery order may be highly desirable, because otherwise 
many messages outside the lawful scope of the order might 
become subject to inspection. 

30 Law Enforcement Auditing Features 

With an escrowed encryption system, there is a concern 
that law enforcement agents might be easily bribed in order 
to obtain cryptographic keys that protect data of high 
economic value. For example, members of a well-funded 

35 criminal enterprise might be able to steal a set of valuable 
industrial plans from a particular company, first by illegally 
tapping that company's communications in order to obtain 
some message headers and escrow agent names, then by 
bribing a low-paid police official to request a warrant for a 

40 drug investigation in order to obtain the company's private 
decryption key from the escrow agents, and finally by using 
the private decryption key to steal the plans. Because 
encryption is now used for secure communication between 
many computers, it is no longer acceptable for law enforce- 

45 mcnt to wiretap a telecommunications system with minimal 
safeguards. A much stronger set of safeguards is needed in 
order to bring police procedures and controls up to the level 
of modem corporate computer security practices and prevent 
this type of situation from occurring. 

50 One such safeguard for the trusted device is an internal 
counter for numbering each message control header, which 
counter will increase sequentially after each access. The 
message sequence number (MSN) can be placed in each 
message header encrypted so that it would not be visible to 

55 an outsider. This can be done by encrypting the number 
either (1) under the sender's public encryption key, along 
with the sender's copy of the message session key, (2) under 
the pubUc encryption key of the escrow agent of cither the 
sender or the recipient, or (3) preferably under at least the 

60 sender, receiver, and their escrow agents, and possibly under 
all parties in the community of interest. However, the 
sender's escrow agent could also, as a matter of policy, elect 
to allow the sequence number to be displayed in the clear, on 
the grounds of economy of space and the low risks of 

65 exposing it. It is critical to avoid duphcate numbers of 
message control headers, and gaps in numbering should also 
be avoided to the extent possible. 
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Another safeguard feature might be to allow the user to Begin Monitoring Date and Time 

include an optional secret "title line" in the message control stop Monitoring Date and Time 

header. If a user feared illegal lapping under improper Maximum Number of Messages (optional) 

warrants, the user could encode a short title, such as "Plan fjudec Sienaturcl 

#123," in order to alert himself and others to the contents of s 1 j p -fi 

the message. Alternatively, a user could simply keep his own Judge L^crtiiicatc 

log (through a mail software system) relating the device- Judge Certifier Certificate (e.g., court, etc.) 

assigned message sequence numbers and the user-assigned The escrow agents could then "recertify" the court's public 

titles. In order to save space the title line would be of length encryption and signature keys to the decoder box by having 

zero if no title was entered, as would often be the case. lO encrypted key split messages from the escrow agents to 

A third protection is to add to the signed portion of the *he decoder box include the following additional 

message control header a digest or hash of the message information, which must be present in each key split from 

contents in order to prevent either the user or law enforce- ^^^^ escrow agent: 

ment from later claiming that the contents of the decrypted Master Escrow Center Name or ID Number 

message were other than as actually sent. That is, for is Monitored User's Certificate Number 

example, the user could not later subsUtute a harmless Escrow Agent Name or ID Number (sending this key split 

message for the drug deal message that had previously been message) 

sent, nor could corrupt law enforcement as officials later q^^^ ^ame or ID Number 

substitute a drug deal or harmless message for the valuable ^^^^ p^^,^^ Encryption Key 

industnal plans the officials were stealme. 20 ^ » i- 

These safeguards could be used as additional security ^^^"^ f ^^nMure Key 

measures. First, the sender device-generated message Warrant Number (if any) 

sequence number would be used to track the message, by Date and Time of Warrant 

both sender and receiver, as well as by law enforcement and Maximum Number of Messages (optional) 

the court system. Although law enforcement access may be is Escrow Agent Signature 

difficult to effectively control, especially during the hot of [Escrow Agent Certificate] 

pursuit of criminals, and although the court system may not The decoder box thus receives the assurance that all the key 

always be able to carefully analyze law enforcement split messages came from the same judge and the same 

requests prior to issuing wiretap authorizations, diligence warrant. 

after the fact can be exercised in order to audit the results of 30 The fact that decoder box also has the judge's public 
a wiretap, either of every wiretap, of a random sample of encryption and signature keys allows the judge to request 
wiretaps, or of wiretaps that in some way appear unusual. and receive (in confidence) the log of all message sequence 
The trusted device of the law enforcement agents, the numbers and message title lines intercepted and decrypted 
decoder box, is therefore modified to include a secure by the decoder box during the wiretap period, as a post- 
internal log of the message sequence numbers and message 35 wiretap audit to safeguard against unjustified, unlawM or 
digests (and title lines, if any) of the messages that it has corrupt conduct of law enforcement agents. Furthermore, the 
monitored and allowed to be read by law enforcement. The decoder box will not delete, erase, or reuse any memory 
electronic authorization sent to the decoder box by the assigned to the monitored message log until the decoder box 
escrow agents of a wiretapped user with that user's key splits receives a separate order from the judge or court, verified 
may also include the public encryption and signature keys of 40 against the previously received public signature key, stating 
the court that issued the warrant. The decoder box is then that the decoder box may do so. Such an order will be issued 
able to respond to a request to print out the log of message either because the court has aheady received from the 
sequence numbers and title lines, possibly encrypted under decoder box the monitored message log that it previously 
the key of a suitably authorized recipient such as the court requested, or because the court has decided that no audit is 
that issued the warrant. 45 needed in this instance. If the monitored message log 
In another embodiment, the decoder box will not start to memory storage area becomes full, the decoder box will not 
decrypt the monitored communications until it receives a decrypt any more messages until the log is sent to the judge 
specific court order that matches the key splits received from or court and an order signed by the court is received 
the escrow agents. For example, the key split messages that allowing the decoder box to erase the monitored message 
are received from the escrow agents and encrypted using the so log. Law enforcement can continue to intercept new mes- 
decoder box's public encryption key can be enhanced to sages pending clearing of the monitored message log, 
include (from each escrow agent) the public encryption and although the new messages will not be decrypted until the 
signature keys of the court that issued the warrant. Or, the full message log has been cleared for audit. The decoder box 
escrow agents might refer in their key split messages to the will also have a feature alerting law enforcement that the 
date and number (if any) of the warrant, and the decoder box 55 monitored message log is nearing capacity, so that they can 
might then receive from the court the court's public encryp- request that the message audit log be uploaded so that the 
tion and signature keys, as well as the court's public key decoder box will not cease decrypting. These transactions 
certificate that had been attached to the original wiretap and communications may be fully automated and nearly 
authorization. For example, the court authorization to the instantaneous. 

escrow agents can be enhanced to convey the following data, 60 Each entry in the audit log may contain, in addition to a 

which is needed for the key split message: digest of the message, a second digest that is the product of 

Master Escrow Center Name or ID Number (a) the message digest plus (b) the full text of the previous 

Monitored User's Certificate Number ^^^^^^ concatenated together and redigested. This can 

^ XT iT^ XI u prevent any dishonest court personnel from adding, deleting 

Court Name or ID Number resequencing the entries in the log. This concept is 

Warrant Number (if any) discussed in U.S. Pat. Nos. 5,136,646 and 5,136,647, which 

Date and Time of Warrant are hereby incorporated by reference. 
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As a followup action, the courl could later request that law In order to further distinguish the caller's and callee's 

enforcement submit the message headers and the full content packets after the communication, it will also be desirable to 

of the message digests in the audit log that tlie court has include a call party code (CPC) with a simple coding scheme 

received. Also, in its wiretap authorization, the court could assigning numbers to the parties to the communication, such 

artificially limit to less than full message log capacity the 5 as caller=0, callee=l, and any additional parties to the same 

number of monitored messages that may be decrypted by the encrypted session receiving higher numbers. Or, in place of 

decoder box before the monitored message log aad message cPC, a unique idemiflcation number, such as the device 

headers must be audited. Although this type of hmit wodd „„^ber, the device serial number plus the device 

have no effect on the overall ab.hty of law en orcement to ,d number, or the hash of the foregoing, may 

investigate, because downloading of the log to the court for . , & J 

auditing is almost instantaneous, it might alert the court to ' j ,j i i_ . . , ^ 

unusual circumstances. In specific cases that require controls "'^^^^^^ generalized as a method for 

that are stronger than merely sending the monitored message multi-party session key generalion. For example, a caUer 

log to the court, the court might limit law enforcement to less ^^^^^ generate a session key and use that same key to initiate 

than fuU message log capacity before law enforcement must several callees simultaneously using RSA key 

seek a new warrant to monitor additional communications. transport. There will then be a separate MCH for each added 

Thus, if (1) both sender and receiver keep track of the P^rty after the first two parties (caller and callee). The 

sequence numbers of the messages they send and receive, caller's device could treat the multi -party call as separate 

and either associate title lines in the message control headers calls or as a single call having the same session key but 

or log the messages in their local software systems, (2) both having multiple CPCs. Each callee would then be respon- 

law enforcement and the court retain a complete log of each 20 sible for using the caller's MSN and for maintaining its own 

message decrypted by law enforcement, and (3) each mes- CPC and PSN. Alternatively, assuming use of conventional 

sage header includes a digest of the message in order to two-party session key generation methods (such as Diffie- 

prevent any party from later altering the message to cover up Helhnan methods), conference calls could exist in which a 

its actions, then a credible post-tapping audit can determine central party (e.g., a system operator) places all the calls and 

whether there might have been any abuse or corrupt action ^5 performs real-time decrypting and re-encrypting of each 

by the law enforcement agency. Although this system still ^ty's packets for aU the others. The central party could also 

cannot prevent, a pnori, the stolen plan scenano menUoned ^e the individual who patches in the next callee, in which 

above, the loiowledge by the cnmmal enterprise that its ^^^^ ^^^^^.^ j^^^^ ^^^j^ decrypted by that indi- 

actionscanbefully audited by both the court and the subject *j ^ ■ j . j • /i. 

-J -*u u 1 u 1 • 1- vidual s device and then re-encrypted using the session 

users can provide a worthwhile check on improper police , / \ n ■ . • . -.l 

actions. It might also be made a matter of regulation that the ^° ^^^^^^ ^^.^^^^ ? communicate with the oOier 

law enforcement agency record and submit to the court all P^^^y F^'\'^tL B. Schneier, Applied 

messages intercepted under a warrant and aHow the wire- Cryptography, J. Wiley 1994, p. 276, regarding use of 

tapped parties to request an audit of the wiretap, particularly Diffie-Hellman with three or more parties, 

where the subject is associated with a business enterprise ^ Packet Control Header (PCH) could be formulated as 

and no criminal charges are filed based upon that wiretap. 35 follows: 

Stream -Oriented Data Original Caller's MSN 

In communications involving stream-oriented data, such ^^^^ p^rty Code (CPC) (caller =0, etc.) 

as a telephone call, in which each communication consists of f t ^ 1 ^ o kt v /t^oktx 

, f f 1 1 * r 4 User Packet Sequence Number (PSN) 

a stream 01 several message packets Irom two or more users, ^ ^ ' 

it is impossible for the sender device to hash and sign the 40 Time Offiset from call setup (msec) 

entire message as part of the MCH. Although it might be Hash (of this packet) 

possible to send a MCH with each packet of a [Device signature] 

communication, doing so would be very costly in terms of It might be preferable not to send a PCH with each packet 

processing time and network bandwidth. Hence, the MCH of communication, due to resulting heavy overhead in some 

should thus be transmitted only once, at the time of call 45 systems that use short packets, but rather to send the PCH 

setup. A preferred way to handle continuous streams of only periodically. This is akin to the technique known as 

encrypted data is to designate the calling user as the "sender" "sliding windows" in network communications, in which 

and to negotiate the MCH at the start of communication, as packet sequencmg and retries are not performed for each 

before, including the message sequence number (MSN) and packet but only for large numbers of packets. Usually such 

hash of the first packet (if any) signed by the device. Then, so systems dynamically adjust the "window," or the number of 

the sender's device could generate a series of unique packet packets that are sent between error checks, based on line 

sequence numbers (PSN), whose sequence begins with zero noise, i.e. making the window large for a clear Une but 

at the start of each communication. For all subsequent making it small for a noisy line that is causing many error 

packets, the device needs only to hash and sign that par- retries. If errors occur often, a small window would require 

ticular packet, and to include (and sign) the hash, MSN 55 the user to resend only a small amount of data; if errors are 

(same for entire message) and the PSN for the packet. The rare, checking can be performed infrequently, albeit with a 

callee will perform similar actions for each packet it sends, high cost to resend lost data in case of an error. Packet 

by referencing the caller's MSN for the communication, control headers could be directly integrated into the sliding 

sequentially numbering its own packets starting with zero, window scheme of a communication system, thereby pro- 

and having the callee device sign a group consisting of the 60 viding the desired capacity to audit law enforcement actions 

packet hash, the caller's MSN and the callee's PSN, thereby down to the packet level, while also allowing maximum 

forming a "packet control header" (PCH). The devices might system throughput in a modem communications network, 

optionally include the current time as an offset from the time To further strengthen the audi lability of the wiretap 

start of the communication (in seconds or milliseconds), process, it is advantageous to positively mark the end of a 

which is already present in previously disclosed versions of 65 communications session with some special packet. This 

the MCH. This could enable the call to be replayed more packet may be sent automatically by each device to the 

realistically. others prior to disconnecting, unbeknownst to the users, in 
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order to prevent either the users or law enforcement agents 
from later claiming that a conversation either had or had not 
ended, when the opposite in fact occurred. This could be 
accomplished by instructing each device to accept a "want 
to hang up now" input from its human user, whereupon the 5 
device would send out a "prepare to disconnect" packet, 
which would then stimulate the other device(s) to do the 
same. The dcvicc(s) would terminate their data streams with 
a "final" packet containing no additional data but preferably 
including the totals of all packets sent and received, call lO 
duration, etc. 
Timestamp Device 

Another feature of this invention in its preferred 
embodiment, as discussed above regarding the decoder box, 
is a trusted and tamper-resistant timestamp device that 15 
self-certifies that it can issue (or a£5x) digitally signed 
timestamps (or data structures containing such timestamps) 
that can be considered trustworthy by third parties. Such 
timestamp devices are described in U.S. Pat. Nos. 5,001,752 
and 5,136,643, by Addison M, Fischer. In its preferred 
embodiment, shown in FIG. 21, the timestamp device 210 
(or subsystem) can be calibrated and set into operation only 
by a trusted authority, such as the manufacturer or one 
trusted by the manufacturer, in much the same way that a 
postage meter can be set only by the local United States 
Postal Service branch ofiSce and is from then on tmsted by 
the public and the postal system to dispense postage-meter 
stamps only up to the prepaid amount. Once calibrated, the 
timestamp device 210 (or subsystem) will respond to a 
"time-set" instruction 211 (or recalibration) only if that 
instruction is signed either by the manufacturer itself or by 
an entity that has attached a certificate 212 from the 
manufacturer, or one trusted by the manufacturer, stating 
that the entity is trusted to set and calibrate the timestamp 
device (or subsystem) of the host device. The time-set 
instruction operation would probably need to be performed 
in person with the time setting authority taking momentary 
physical possession of the device and immediately erasing 
the time -set instruction 211 in order to prevent the possibil- 
ity of a device owner capturing the instruction and replaying 
it at a later time in order to "back-date" a device's clock. 

Once calibrated and for as long as it is undisturbed, the 
timestamp device 210 will aflSx timestamps 213 or complete 
timestamp data in structured data fields based upon its 
internal clock mechanism, signing 214 the resulting data 
structures with its private device key and furnishing its 
manufacturer certificate 215. If the host device should lose 
power, be tampered with or receive an instmction to deac- 
tivate itself, the timestamp device will cease issuing times- 
tamps. In that case, in order to avoid impairing other 
possibly useful functions that do not as an absolute matter 
require trusted timestamps, the timestamp device will utilize 
a convention, such as filling the timestamp field with a 
pre-agreed "null" value, such as all binary zeros or binary 
ones (or an equivalent convention), when a structured data ss 
field calls for a timestamp to be entered. However, when a 
structured data field or the host device requires that an actual 
timestamp be issued, such as in the case of a law enforce- 
ment decoder box, if the timestamp device has ceased to 
issue timestamps, the host device functions that require 60 
timestamps will not operate; in the case of the decoder box, 
the box will refuse to decrypt intercepted commimications. 
In order to avoid or minimize the occurrence of the situation 
of lost host device power each trusted timestamp device 
should preferably be equipped with its own separate long- 65 
lived battery 216 for clock use only, some "low battery" 
warning indicator to prevent timestamp device loss of power 
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before a battery change and some means of retaining an 
adequate electrical charge (such as a storage capacitor, a 
second battery compartment or an optional external power 
supply) during battery change operations. 

For each timestamp issued by the timestamp device, there 
could be a timestamp device certificate issued by the manu- 
facturer (or another time-setting authority) stating the qual- 
ity and reliability of the timestamp clock, the date on which 
it was last set, as well as its expected time drift. When a 
recipient user receives a data structure that has been digitally 
signed by the host device, that recipient knows that, if the 
timestamp field is completed with a valid value, the device *s 
signature and certificate certify that the time was correct 
when the data structure was created, signed and issued. This 
certification is based on (1) the trustworthiness of the 
authority that most recently calibrated the timestamp clock, 
(2) the clock's drift tolerances as stated by the manufacturer 
in the device certificate, and (3) the clock's ability to 
deactivate itself upon tampering or a loss of power. The 
recipient further knows that, if the timestamp field contains 
a "null" value, then the timestamp clock was not in a state 
of trusted calibration at the time the device created, signed 
and issued the data structure. This information concerning 
the trusted properties of the timestamp device and its inter- 
nal clock mechanism can be preferably encoded directly into 
the device certificate using a suitable attribute-value coding 
scheme. However, this information could also be implied 
from the manufacturer name and device type, which could 
be published by the manufacturer in a specification and 
performance certification as part of a publicly stated "policy 
statement" at the time the device certificate is issued. 

Such timestamps could also be issued by the device as 
part of other message handling operations beside MCH 
creation and decoding. These timestamps could be attached 
to the personal signature of the device's user when the user 
signs another document or transaction using his personal 
signature key, which is securely confined inside the device. 
The device would sign or co-sign the timestamp element of 
the user's signature, or might alternatively sign over the 
user's entire signature block (which contained the 
timestamp, also signed by the user, along with the hash- 
result message digest of the document). The device could 
then supply its certificate in order to make the timestamp 
believable and trustworthy to a third party who knows the 
manufacturer's public key. 
Trusted Upgrading, Replacing and Rekeying 

Another feature of this invention is a tamper-resistant 
trusted device that contains an embedded manufacturer's 
public key, a protected non-volatile memory area and a 
secure central processor unit (CPU) and can upgrade or 
supplement in a trusted manner any firmware routines 
embedded by the manufacturer. The trusted device does the 
upgrading or supplementing by accepting as input a body of 
data containing new or additional firmware code that is 
suitable for that type of device and is digitally signed with 
the manufacturer's signature, which signature assures the 
device that the new firmware code has been developed, 
tested and approved by the manufacturer and that the device 
should therefore either (a) overlay one or more currently 
embedded firmware routines with the new firmware code or 
(b) add the new firmware code as one or more new routines 
in a currently unused area of protected memory In the 
preferred embodiment, the protected memory would be of 
the FLASH type, which can retain its information indefi- 
nitely while powered down but can also be erased by 
Ihe-device (albeit, relatively slowly) and reused if desired. 
The protected memory could also include any data storage 
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area (such as a disk drive), whether or not tamper-resistant, 
in which the code to be upgraded or supplemented could be 
stored in an encrypted form for which the decryption key is 
known only by the trusted device. By storing the programs 
in an encrypted form, the device effectively prevents them 
from being modified by anyone without knowledge of the 
decryption key. When the device receives such a signed 
body of new firmware (or software) code, the user inputs the 
code along with the manufacturer's signature and issues a 
"process firmware upgrade" instruction to the device. The 
device then verifies the manufacturer's signature using the 
public signature key of the manufacturer, which was embed- 
ded in the device during manufacture. If the manufacturer's 
signature verifies, the code is accepted and the device 
performs the desired upgrade. 15 

The process of a trusted upgrade to the firmware of a 
trusted device as described above can be further extended to 
accommodate authorized third parties that desire to upgrade 
firmware routines that pertain lo device functions relevant to 
those third parties, including functions such as the present 20 
key escrow system, which may be largely designed and 
administered by a bank master escrow center independently 
of the trusted device manufacturer. In an instance of third 
party upgrade, the manufacturer could sign a firmware 
upgrade certificate containing a public key of the third party 25 
firmware provider and issue it to that third party. TTie third 
party could then develop, test, and approve replacement or 
additional firmware routines, sign them with the third par- 
ly's private signature key, and attach its upgrade certificate 
from the manufacturer thereto. Upon receiving such an 30 
upgrade, the user would load both the signed code routines 
and the manufacturer's upgrade certificate into the device 
and then issue a "process third party firmware upgrade" 
instruction. The device would then verify the third party's 
signature on the new code routines against the manufactur- 
er's upgrade certificate and then verify the upgrade certifi- 
cate against the manufacturer's public signature key that was 
embedded in the device during manufacture. If both signa- 
tures verify, the upgrade is accepted and the device performs 
the desired upgrade. 

In addition to accepting instructions to upgrade or supple- 
ment device firmware routines, a tamper-resistant trusted 
device can also accept instructions to replace or supplement 
"instructions" public keys that were embedded during manu- 
facture. As discussed earlier, a trusted device may have 
public keys besides those of the manufacturer embedded 
during manufacture of the device. Such "instructions" public 
keys might include those of one or more master escrow 
centers as described in the present invention. These embed- 
ded keys, including those of the manufacturer or other 
trusted third parties, can be used to verify various certificates 
such as escrow certificates, device certificates, upgrade 
certificates, time-set instruction certificates and others that 
may be presented to the device for it to act upon. In addition 
to relying only on public keys embedded during 
manufacture, the device can also accept external instructions 
to embed new public keys or lo replace existing ones. In 
order for a device to accept and store in a non-public area the 
public signature key of a trusted third party, the manufac- 
turer will enclose the new public key in a signed instruction 
data packet (or certificate) signed by the manufacturer 
instructing the device to discard the enclosing certificate and 
store the designated pub he instructions key within. The 
special packet may also instruct the device as to what types 
of transactions the new key is trusted (e.g., for use with a key 
escrow application, car rental application, medical data 
application, or other use). Upon receiving such a public key 
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data packet from the manufacturer, the device would first 
verify the manufacturer's signature and then accept and 
store the new public key along with the restriction on the 
pubhc key's use. 

The manufacturer may also designate at the time of 
embedding a third party public instmctions key, either 
during manufacture or later as part of an instmctions data 
packet, that one of the transactions for which that third party 
key is approved is the replacement of the manufacturer's 
own underlying pubUc signature verification key. Although 
such a replacement of the manufacturer's own public sig- 
nature key should almost never be required, there is the 
chance that the manufacturer's corresponding private sig- 
nature key (for issuing device certificates and other instruc- 
tions to the device) might be compromised through theft. 
Theft of the manufacturer's private signature key would 
allow the thief to issue seemingly valid instructions, to 
approve new escrow centers (of dubious trustworthiness) 
and to approve new time set authorities. Alternatively, and 
more likely, the manufacturer's private signature key might 
simply be lost or destroyed, thus preventing the issuance of 
any further valid instructions. Either of these events would 
be classified as a "disaster" in computer systems terms and 
could result in all of that manufacturer's devices having to 
be recalled. However, through the present invention, the 
expense of such a recall could be prevented or mitigated by 
allowing a trusted third party to replace the manufacmrer's 
compromised signature key. Assuming that the manufacturer 
had already embedded the instructions keys of one or more 
trusted third parlies into the device, either during manufac- 
ture or later using an instructions data packet, and had 
included the replacement of its own public key among the 
transactions that the third party's public instructions key 
could approve, the manufacturer could then turn to that 
trusted third parly and request that it issue an instrucfion data 
packet to all of the manufacturer's devices authorizing the 
replacement of the manufacturer's public signature key, thus 
saving itself and its users the potentially huge expense of 
physically replacing all the physical devices. Because all the 
device certificates issued by that manufacturer would also 
have to be replaced, this could be accomplished by having 
each device issue a certificate request for the device's own 
public device signature key. If the manufacturer's private 
key was lost or destroyed, and not compromised, then all 
previous signatures would still be valid and a xiser would 
need only to present his old device certificate in order to 
have a new device certificate issued for the same informa- 
tion signed by the manufacturer's new signature key. The 
manufacturer would then return new device certificates 
(most likely via an on-line or an electronic-mail transaction). 
While this would still be expensive, it would be far cheaper 
and less detrimental lo the reputation of the manufacturer 
than the wholesale physical replacement of all of that 
manufacturer's trusted devices in the field. 

The incorporation into the trusted device of the present 
invention of a mechanism to replace a manufacturer's public 
key or any other trusted public instructions key could 
mitigate some of the systemic security risks that are posed 
by the use of system- wide root public keys. This would 
allow greater reliance upon purely hierarchical trust models, 
which generally allow shorter and simpler certification paths 
requiring fewer certificates, less effort to determine which 
certificates to utiUze and less computational time lo verify 
the signatures. 
Owner-Controlled Rekeying 

As previously described, the user also has the option of 
rekeying his device as to its user encryption key pair at any 
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time after manufacture. The user does this by issuing a of the last several rekey instructions it received and refuses 

firmware instruction to the trusted device to perform the to execute the instructions again. Assuming the device's 

particular steps of the key escrow method, i.e. to generate a time clock is maintained in good order, subsequent replay of 

new private and public encryption key pair, send the key the rckey instructions can also be limited merely by instruct- 

splits to the escrow agents and ultimately receive a new S ing the device's time clock to honor the expiration date and 

escrow certificate from the master escrow center. However, time in the instruction. In a preferred embodiment, a device 

it is also desirable to permit a user's employer or sponsor (or whose clock is uncalibrated would refuse to process a rekey 

owner, if the user is another device or process) to control the instruction that has a non-null expiration date/time but 

key and rekey processes in order (a) to make sure that the would proceed if the expiration date/time were left null, 

user selects escrow agents that the employer deems accept- lO Upon receiving from a user device the key (or rekey) split 

able and (b) to assure that the employer, as the true owner share packets containing a unique owner identification 

of the device, will remain known to those selected escrow number, the escrow agents and master escrow center would 

agents and hence will be able to request the user*skey splits record that unique identification number in their respective 

from the escrow agents without having to first obtain a databases and would subsequently honor requests from that 

warrant or court order. The employer may require access to 15 owner for access to the private encryption key. In a prefened 

a particular device's keys for any number of reasons, such embodiment, the escrow agents and escrow center would 

as to conduct internal surveillance or to recover encrypted each require that a key split share packet that designates a 

proprietary data after the relevant device has been lost, unique owner identification number must also be accompa- 

stolen or destroyed. The employer may also need to rckey nied by the respective device ovracr certificate signed by the 

the device for any of a number of reasons, such as for a 20 manufacturer. This device owner certificate would allow the 

device whose previous encryption or signature keys have escrow agents and the master escrow center to act upon key 

been compromised or erased, for a device that has been request messages signed with the owner's private signature 

given to a different employee, or for a device whose owner- key corresponding to the owner's public key in the device 

organization rekeys all cryptographic devices at periodic owner's certificate. 

intervals as a matter of policy. 25 In another embodiment, the trusted device can be allowed 
In the preferred embodiment, the tnisted device is pre-set to accept rekey, reescrow, ownership transfer or other 
by the manufacturer such that it will not initiate the key instructions from the device owner without having to use a 
generation and escrow process unless the device first separate device owner's certificate. The requirement of 
receives an owner's certificate for the device 220, such as having to use a separate owner's certificate for instructions 
one shown in FIG. 22, containing the particular device's 30 to the device is an administrative burden, because the owner 
permanent serial number 221 and signed 225 by the manu- must maintain a database of certificates for all its owned 
facturcr. The owner's certificate 220, issued at the time of devices and locate the appropriate certificate each time it 
purchase by the manufacturer to the corporate purchaser of wants to rekey a device or send the device some other 
the device, also contains the corporation's name 222, the instructions. Abetter approach, as shown in FIG. 26, is to 
corporation's unique identification number 223 (such as 35 have the manufacturer issue the owner a single certificate for 
Internal Revenue Service Employer Identification Number the owner's public instructions key for a given family of 
(EIN) or Dun & Bradstreet Number (DUNS)) and the devices, let the seller install its public instructions verifica- 
corporation's public signature verification key 224, which tion key 261 inside the device 260 when the device 260 is 
corresponds to the private signature key retained by the sold, and then institute a system based on the internal storage 
corporation and which will be used to verify rekey or other 40 of those keys. Upon initial sale of the device by its manu- 
instructions issued by the corporation to the device. Subse- facturer to an owner, the device 260 wiU first verify the 
quent to receiving this information, the device will respond validity of the owner's manufacturer certificate 262 using 
only to rekey or other instructions that are signed using the the manufacturer's public instructions key 263 that was 
corporate owner's private signature key corresponding to the embedded within the device by the manufacturer. If the 
public key contained in the device's owner's certificate. 45 owner public instructions key area 264 within the device is 
Referring now to FIG. 23, when the employer (the owner blank, the device will copy the owner's public instructions 
of the device) desires to rekey the device 230, the employer key 261 from the owner's manufacturer certificate 262 into 
issues a signed instruction 231 to the device 230, including the owner public instructions key area 264 of the device. If 
(1) the device's serial number 232, the unique owner iden- an owner public instructions key already exists in the device 
tification number 233, (2) the names of the escrow agents 50 and is different from that of the owner attempting to initial- 
235 and the master escrow center 234, (3) the date and time ize the device, the device assumes that the manufacturer has 
of the rekey instruction, (4) the date and time of the rekey sold the device to another entity. Because each device will 
instruction expiration 236 and (5) the rekey instruction have at most one primary owner, ownership of that device 
unique serial number 237, and signs the instruction using the will be determined by the presence or absence of an owner's 
employer's private signature key 238. Upon receipt of a 55 public instructions key 261 inside the device 260, in lieu of 
valid owner's certificate 239 and a valid rekey instruction (or in addition to) the prior concept of an owner's certificate. 
231, the chip within the trusted device 230 first verifies the If no owner public instructions key is installed, the device 
manufacturer's signature on the owner's certificate 239 and is considered to be a single-user consumer device that is 
the employer's signature on the rekey instruction 231. The unrestricted with regard to rekeying or ownership transfer of 
trusted-device then completes the key generation and escrow 60 the device; as such, the device will consider the non- 
process, as before, including the owner's unique identifica- existence of an installed owner's key as a signal to obey the 
tion number 233 within each escrow share packet, and sends user's instructions without invoking the rekey, reescrow and 
the share packets only to the escrow agents 235 designated ownership transfer rules discussed above. If an owner public 
by the employer in the rekey instruction 231. Subsequent instructions key 271 has been installed within the trusted 
replay of these instructions (which may be issued 65 device 270, as shown in FIG. 27, then user rekey, re -escrow 
electronically) can be limited by designing the device so that and ownership transfer instructions 272 will not be pro- 
the device retains in non-volatile storage the serial numbers cessed unless those instructions are signed 273 by the 
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corresponding owner private signature key 274. Once the 
owner's signature 273 has been verified, the trusted device 
270 performs the steps of the re-escrow procedure, as 
described previously. Thxis, the owner need not append ao 
owner's certificate proving his ownership of a given num- s 
bcred device when instructing that device. However, the 
owner's signed instructions must of course be limited to a 
numbered device or perhaps to some class of devices whose 
device numbers conform to a given rule or template, in order 
to prevent the instructions from being fed into every device lO 
owned by that owner. 

In addition, as shown in FIG. 28, the owner can send an 
instruction to transfer device ownership by replacing the 
originally-installed owner public instructions verification 
key with another (from the buyer, the new owner of the 15 
device). The device owner sends an ownership transfer 
instruction 282 to the device 280, including the new owner's 
name and public instructions verification key, signed using 
the current owner's private instructions signature key 283. 
The device verifies the ownership transfer instruction 282 20 
using the current owner's public instructions key 281, 
replaces that key with the new owner's public instructions 
key 284 and thereafter responds to instructions only from the 
new owner In addition, the owner could also add another 
"secondary owner" by installing a second public instructions 25 
key. This second public instructions verification key would 
have a "rights" field, indicating for which operations it is 
authorized to accept instructions. Among those rights might 
be: rekey, addition of another owner, deletion of an owner 
(same as a conditional sale), deletion of all owners, and 30 
reverting back to a consumer device having no stated owner. 
However, these defined rights may include more or fewer 
rights than, or the same amount of rights as, the original or 
primary instructions verification key, including the right to 
replace or remove the primary owner instructions key. 35 
Generalized Device Registration 

Note that the foregoing general methods for escrowing a 
private decryption key and receiving an escrow certificate 
can also be applied to the more general case of registering 
a trusted device with a trusted third party and receiving an 40 
authorization from that third party enabling the device to 
communicate with other trusted devices, not necessarily 
limited in scope or purpose to the key escrow situation. In 
this general process, depicted in FIG. 24, a programmable 
trusted device 240 that communicates with a trusted third 45 
party (TTP) 241 is equipped with a private signature key and 
a manufacturer's certificate 242 for the corresponding public 
signature key. It also contains secure copies of the manu- 
facturer's and system wide (or global) authority's (SWA) 
public keys, which could be the same, and secure system- 50 
level iirmware that can support the remote installation of 
additional application-level firmware and related public 
keys, as discussed elsewhere in this disclosure. The device 
240 can register with any one of a potentially unlimited 
number of TTPs 241 that are admitted into this genera] 55 
registration system by having been issued a certificate of 
authority 243 signed by the SWA (the SWA could also 
appoint an additional tier of certifiers to authorize TTPs to 
be admitted to the system, in accord with well known 
principles of public key certification hierarchies). Once 60 
u.sers have registered their devices with a given TIP, they 
can then engage in specialized transactions with other trad- 
ing partners. 

In the first step of this process, the user initiates a request 
244 to register his device 240 with a given certified TTP 241. 65 
This request 244 contains some information 245 to identify 
the user and the nature of the registration request and is 
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signed by the device and accompanied by the manufactur- 
er's device certificate 242 in order to vouch for the signature 
and the known type of the device . The selected TTP 241 may 
also request other information and assurances from cither 
the user or from other parties to verify the user's identity, 
affiliation, credit worthiness, etc., which arc outside the 
scope of this protocol but may influence the 1 I P's decision 
to grant or deny the desired authorization to perform trans- 
actions. The TTP 241, using the appropriate public keys, 
verifies the manufacturer's signature on the device certifi- 
cate 242 and the device signature on the information 245 in 
the user's registration request 245. 

When satisfied that the user can be permitted to engage in 
the requested class of transactions, the TTP 241 then issues 
a response 246 containing a certificate 247 specifically 
authorizing the device to perform those transactions on 
behalf of the user. The TTP's device authorization certificate 
247 will typically contain information identifying the TTP, 
the tiser, the user's device, and the transactions for which 
permission is granted, as well as a recertified copy of the 
user's device public signature key as a matter of conve- 
nience (and as later discussed) so that the user need not 
submit his device certificate 242 in each subsequent trans- 
action with trading partners. The TTP response 246 may also 
contain downloadable firmware and or public keys 248 to be 
loaded into the user's trusted device to enable it to perform 
the authorized transactions. Where the TTP response 246 
calls for the user to securely load new firmware or public 
keys into his device, the response 246 will also include the 
TTP's certificate of authority 243 issued by the SWA certi- 
fying the TTP's public signature key and conveying firm- 
ware and public key upgrade authority. When the user's 
trusted device 240 receives the TTP's response 246, it uses 
its embedded SWA public signature key to verify the TTP's 
certificate of authority 243 and tises the TTP public signature 
key contained therein to verify the firmware and public key 
upgrades 248 and the TTP's device authorization certificate 
247, 

Referring again to FIG. 24, when the user wishes to 
perform a transaction with a trading partner 250, its device 
will formulate the transaction data 249 in accord with the 
mles embodied in the firmware program installed on the 
device (either at time of manufacture or upon subsequent 
downloading), as has been extensively discussed throughout 
this disclosure, and will sign the transaction 249 and attach 
a certificate for its corresponding public key. This certificate 
could be the manufacturer's device certificate 242 but will 
more likely be the TTP's device authorization certificate 
247, which contains a copy of the device public key recer- 
tified for convenience. The trading partner 250 will typically 
utilize the public key of the TTP to verify the TTP's 
signature on its device authorization certificate 247 and then 
use the device public signature key contained therein to 
verify the device's signature on the transaction 249, thereby 
confirming the device's compliance with the transaction 
protocol requirements imposed by the relevant firmware. In 
the event that the trading partner 250 does not already have 
the specific TTP's public signature verification key, the user 
can include in his transaction 249 the TTP's SWA certificate 
of authority 243, which the trading partner can verify using 
the SWA public key, which it must already possess in order 
to be a participant in this system. 

The generalized process thus far described is general 
enough to allow (a) the escrowing of a private encryption 
key in return for an escrow certificate signed by an escrow 
center (TTP), where the information contained or implied in 
the user device certificate conveys to the escrow center that 
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the device is already equipped with firmware that is capable investigator's request is signed using the employer-owner's 

of performing the specialized functions of the herein- signature key (i.e., the investigator has authorization from 

described key escrow encryption system, or (b) if such the employer-owner to investigate), the master escrow ccn- 

dcvicc is not so equipped but is capable of becoming so ter would reveal this information. If the investigator has no 

equipped, the downloading of a secure software upgrade that 5 authorization, the investigator would then be required to 

upon installation will enable the device to fulfill the escrow seek a warrant or court order to investigate suspicious 

system transactional requirements. The transaction data 249 ^^^ti^ity reflected in MCHs of unknown device owners. It is 

sent to the trading partner 250 can be an encrypted message anticipated that most device ownets wiU not object to being 

prefixed by a message control header and accompanied by ^P^^V ^^^^ ^^f'' ^^^^ « cerUficates and MCHs, 

an authorization 247 (the user's-escrow certificate), as lO b^^^^^^f. ^^^^ ^l^^tronic communications systems it is 

issued b a TTP 241 Cthe aster e c ow te impractical to suppress the physical and logical network 

™ ^ , . . c T^r^ I r address information that often strongly identifies the sending 

Tbe generalized system of FIG. 24 therefore possesses ^^^^^^j institution of a given message. Thus, little is 

many highly desirable properties which can facihtate com- i^gt ^y publicizing the unique owner identification numbers, 

plex forms of business and government transactions m open ^^d much is gained by providing the ability to quickly sift 

communication network environments. In particular, there 15 and sort messages by sender device owner and recipient 

can be many different device manufacturers, as long as each device owner names. 

participating device is able to execute secure multi-step The unique owner identification number may, however, 
transactions, download firmware to perfonm additional types still be included within the employee's escrow certificate or 
of secure multi-step transactions, and sign the transactions within the MCHs of communications without being publi- 
so created. Also, there can be any number of trusted third 20 cized. The employee's escrow certificate and MCHs would 
parties, each issuing a different type of transactional autho- include an Employer Public Encryption Key along with the 
rization and each creating and certifying a different class of other keys as described above. These keys would normally 
firmware application, such as key escrow, digital cash be present in both the sender's and recipient's escrow 
management, car rental or user medical records manage- certificates (assuming that both sender and recipient have 
ment. Thus, although a trading partner may be required (by 25 employers). When the sender's device forms the MCH, it 
the user device's firmware and protocols) to utilize a com- will incorporate into the MCH one or both employer unique 
par ably equipped tmsted device, that device may be made, identification numbers, each encrypted using the public 
issued and equipped by different parties than those of the encryption key of the respective employer so that, in effect, 
original user, yet the original user's transactions will still be the sender's device uses the MCH to send to each employer- 
accepted and processed in accord with the system rules, so 30 owner a message consisting of that respective employer- 
long as the partner possesses a copy of the SWA public owner's own unique ID that only it can decrypt, lliis method 
signature verification key 247, which enables all versions of is similar to that discussed above regarding the sender's use 
the devices and their programs to recognize each other and of the MCH to send the certificate numbers of both the 
work together, if so certified by the SWA and its TTPs. Some sender and recipient encrypted under the public encryption 
examples of business purposes that can be fulfilled by this 35 keys of their respective escrow centers, and to send the 
protocol include systems that enforce transactional require- message session key to the recipient (the MCH's normal 
ments for (a) encryption using provably escrowed keys, (b) function) as well as to the sender in order to allow tapping 
management of digital representations of cash or other of both parties. This technique allows the employer to 
high-value documents, and (c) access to and use of medical readily determine which MCHs belong to its employees, 
or other personal information of the user. 40 while avoiding a situation in which all messages belonging 
Unique Owner Identification Number to the owner-employer's employees are readily identifiable 
Depending on the need to balance ease of use with privacy in the message trafBc flow and in-which owner ID numbers 
rights, the unique owner identification number may also are unencrypted and readily obtainable, 
optionally appear in either (a) the user's escrow certificate or Still, this approach has the drawback that the unique 
(b) MCHs issued during normal communications, as well as 45 employer identification number encrypted using the 
in the key split messages to escrow agents. It would be employer public encryption key will always produce the 
desirable for an investigator attempting to decrypt coramu- same, and thus recognizable, value. A better implementation 
nications to be able to determine by looking at a MCH of this approach would be to encrypt a data block containing 
containing the owner identification number whether one or a current timestamp (or another random number) along with 
both of the devices involved in the communication from so the employee's escrow certificate number (which the 
which the MCH was taken belong to a given owner. employer clearly has the right to know) under the employ- 
However, other privacy interests, including those of certain er's public key, so that the timestamp would give high 
owners, might suggest that the owner identification number variability to the encrypted data block. Several bytes of a 
be omitted from the MCH in order to enhance the privacy of distinct "eyecatcher" text, such as "EMPL" (or possibly the 
communications. In cases in which the owner identification ss employer's unique ID, space permitting) could also be 
number is included only in the device escrow certificate and included inside the encrypted block in order to make sue- 
not in the MCHs of communications, an investigator, hired cessful decryption obvious to an entity that is decrypting the 
by a particular employer in an attempt to determine whether field (in case the other data items arc in binary, in which case 
a particular communication originated from employees of one might not know for sure). In this case, proof of the 
that employer, confronted with many MCHs that have no 60 employer's ownership consists of the employer merely 
listed device owners, would inquire of a master escrow being able to read this field. In addition, yet another random 
center listed in a given MCH whether that MCH originated number could be added to the data block for increased 
from a device owned by the employer. The master escrow variability, in case the timestamp is not sufficiently trusted to 
center would decrypt the certificate number of the party to be different each time and to therefore make all employer 
the MCH communication whose keys are escrowed with that 65 MCH data blocks unique. 

master escrow center and check whether that user certificate This improved approach, which would be done for the 

was issued to the investigator's employer. If so, and if the employers of both the sender and recipient with every 
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message thai is sent, would make it possible for employers 
and other sponsors to determine which communications 
were generated or received by their employees without 
having to submit the encrypted MCH for every communi- 
cation to the appropriate escrow center for a determination 
as to whether or not any of those communications originated 
from a device owned by that employer, thus probably saving 
a considerable amount of money. Each employer will still 
have to contact the master escrow center and the escrow 
agents, as before, in order to obtain its employee's private 
encryption key, and must prove that it is in fact the owner of 
the employee's device by signing its requests with the 
private signature key that matches the public signature 
verification key contained in its owner certificate as issued 
by the device manufacturer. At least the employers will be 
spared the time, effort and expense of any additional 
requests to those parties regarding the MCHs of communi- 
cations originating from what later turn out to be non -owned 
devices. And, as before, if an employer suspects criminal or 
other improper activity in messages accompanied by MCHs 
from commimicatiorLS by non-owned devices, the employer 
can always contact an appropriate law enforcement agency, 
tell that agency why it suspects criminal activity and have 
that agency go to court to obtain a warrant for interception 
and/or decoding of those communications, which appear to 
be originated by third party non-employee criminals or, 
more likely, by individuals on the employer's premises, 
whether employees or not, who are using encryption devices 
not owned by and registered to the employer. 

This method of placing information in the MCH 
encrypted so that the information can be read only by the 
party entitled to read it can obviously be extended to parties 
in addition to the sender and recipient (each of whom can 
decrypt the message session key), each party's master 
escrow center (each of which can decrypt its respective 
user's certificate number), and each party's employer-owner 
(each of whom can decrypt its employee's certificate num- 
ber or its own unique owner identification number, so as to 
ascertain whether it owns the communicating device without 
having to contact anyone else, while avoiding being iden- 
tified on every message). This can also be extended to other 
parties such as divisions within a very large company or, for 
example, local law enforcement in certain foreign nations 
that have no warrant requirements. Of course, all the infor- 
mation encrypted under these keys could also be shown in 
the clear, i.e. unencrypted, as discussed earlier, providing 
that these parties have no objections to being openly named 
and routinely identifiable on every message. This infonna- 
tion can also be omitted whenever a parly is irrelevant, for 
example when a user has no employer. The simplistic 
approach would be to use one MCH format for all situations, 
leaving fields blank when inapplicable. Otherwise, the pre- 
ferred embodiment would be to utilize various different 
MCH formats within the same system, each format being 
identified by a unique version number in the first field, such 
that each device processing a MCH would be able to 
determine which fields to expect and parse the MCH accord- 
ingly. This method would allow for an indefinite nesting of 
interested parties in the MCH, which would be the most 
flexible possible system. The computational overhead would 
depend mainly on how many of those fields actually had to 
be encrypted under each respective party's public encryption 
key. 

An employer can more easily control the information that 
is included in the MCH by accompanying each entry with a 
"poHcy field" or an instructions code containing code 
instructing the employer's device as to what information to 
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include in the MCH. As before, the instructions code could 
include elements of choice giving the employer options of 
including the following information: (1) the employer's 
name and unique identification number, either encrypted or 

5 using an alias; (2) the word "employer" unencrypted, with 
the employer's unique identification number encrypted 
inside a MCH field; (3) the user certificate number in an 
encrypted field; (4) the message session key in an encrypted 
field; (5) a timestamp in an encrypted field; and (6) a random 
confounder number within any of the other encrypted fields. 
Many of these options can be in effect simultaneously. In 
addition, these policy options would be the same for all 
members of the community of interest, including the parties 
to the communication themselves, thereby allowing the 
parties to be labeled by their mail or system IDs or simply 

1^ by using the word "sender" or "receiver" in the relevant 
clear MCH fields. 

Multiple Simultaneous Escrowed Keys 

In addition to the above-described features for upgrading 
device firmware routines and for replacing manufacturer's 

20 public keys, the trusted device of the present invention 
should also have the ability to maintain and manage several 
sets of escrowed encryption keys simuUaneously. Normally, 
when the device begins the cycle of rekeying, i.e., generat- 
ing and escrowing a new private decryption key, and as a 

25 result receives an escrow certificate for the corresponding 
new public encryption key, the device will erase the previous 
private key in order to force reliance of the device on the 
newly escrowed private key. Alternatively, the device could 
retain the previous private key for only a short time as 

30 needed, e.g. for the time needed to recover data encrypted 
into data storage using the previous private encryption key. 
However, in an alternate embodiment, the device may also 
accept and process a re -escrow instruction, either from the 
user or from the device owner as described above, to create 

35 a second valid escrow certificate concerning the same 
private/public encryption key pair. In this embodiment, the 
device would proceed with the escrow process using quite 
possibly a different list of escrow agents and a different 
master escrow center, and would receive a different, equally 

40 valid escrow certificate for the same public/private encryp- 
tion key pair that is signed and issued by the second master 
escrow center and can be used interchangeably with the first 
escrow certificate. This second public encryption key cer- 
tificate can be of use in cases in which the device's user 

45 travels internationally or corresponds with parties located in 
other countries, especially when those other nations may 
desire to conduct lawful surveillance of communications 
originating or tenninating in that other nation. In such cases, 
by re -escrowing the same device key in another nation, the 

50 user (or the user's employer) could help to satisfy possible 
legal requirements in that other nation, while still allowing 
the user or employer the convenience of doing business with 
the original set of escrow agents in his own nation (lawful 
owner monitoring, recovery of lost key, etc.). Then, in order 

55 to allow the owner to track its employees' MCHs, it may be 
enough if the sender and recipient owner IDs appeared in 
each MCH, thus telling the owner that it does indeed have 
the ability to obtain the key. To save time and effort, the 
owner may then send such an MCH to the foreign master 

60 escrow center to obtain the foreign escrow certificate 
number, the underlying device number and the underlying 
device certificate, but then apply to its domestic escrow 
agents who can verify the owner's certificate already in their 
possession and release the actual private key splits. This 

65 procedure relieves the device owner of any extra legal 
formalities that might be required in order to obtain the 
actual key splits from the foreign escrow agents. 
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National Security Export Safeguards 

The current policy of the United States government is to 
allow unregulated use of encryption within the United Stales 
by American citizens but to impose heavy restrictions and 
penalties for the export of encryption devices, software or 
know-how. It is possible to modify the present system to 
allow relatively free private use of cryptographic devices in 
the United States while simultaneously imposing restrictions 
on their international use. Such a system could allow sepa- 
rate inter-operable "poUcy domains" that are open to all 
software and hardware vendors with minimal or no design 
changes to the standard message formats used throughout 
the system. It is further desirable to allow the use of private 
escrow agents in purely intra-corporate, single country 
situations, in which the key escrow system is being used 
solely to allow a particular corporation to monitor and 
control its own employees^ uses of encryption, without any 
obligation, express or implied, to facilitate law enforcement 
access to communications that have been encrypted using 
keys the corporation has escrowed. In particular, such com- 
panies might buy the software and hardware for their own 
use but might decline to assume any public duty to provide 
access to private keys in short time frames, as might be 
desired by law enforcement in hot pursuit of criminals or 
terrorists. 

This can be done by first assuming that all devices 
throughout the system are linked directly or indirectly to a 
system-wide authority (SWA) that (as previously disclosed) 
issues certificates to escrow agents, master escrow centers 
and device manufacturers in order to enable each to be 
recognized by devices within the system as being authentic 
and trustworthy. A national or global communications sys- 
tem must for practical purposes support the existence of 
multiple and unrelated master escrow centers and agents, 
each of which must be certified by the SWA as being 
authentic. In each certificate issued to a master escrow center 
or to an escrow agent, the SWA will designate it as either 
"public" or "private." A "public" roaster escrow center or 
escrow agent is one that is equipped and committed to 
respond promptly to national security or law enforcement 
warrants and subpoenas. Users whose keys are escrowed 
with such agents may be permitted to engage in transborder 
communications. A "private" master escrow center or 
escrow agent includes those single-company or single- 
country key centers that have installed key escrow system 
technology for their own use but do not undertake any 
commitment to a public level of service. The certificate from 
the SWA to the master escrow center or escrow agent wiU 
also include a country code. Then, each user's escrow 
certificate that is issued and signed by a master escrow 
center and has the master escrow center SWA certificate 
attached will also carry the user's country code. Note that, 
as a matter of convenience, the user's escrow certificate 
should also state that it originates firom either a public or 
non-public escrow agent, although it may not be possible for 
the SWA to enforce the correctness of that information. This 
could allow the device to enforce these rules even more 
easily than always requiring the master escrow center's 
SWA certificate. 

FIGS. 29 and 30 show the enforcement of the escrow 
requirement when sending and receiving international cryp- 
tographic communications. As shown in FIG. 29, the trusted 
device 290 of the sender enforces this system by requiring 
the escrow certificates 291,293 of both the sender and the 
recipient, and, if the sender and recipient are not escrowed 
with the same master escrow center, their master escrow 
center SWA certificates 292,294, prior to sending an inter- 
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national communication. The country codes 295,296 of the 
recipient user and its master escrow center must match in 
order for a sending device 290 to send a communication. 
Furthermore, if the sender and recipient are in different 

5 countries 295,297 and if either user is using a non-public 
master escrow center 298,299, the sending device will refuse 
to originate a communication to that recipient. As shown in 
FIG. 30, the recipient trusted device 300 will also enforce 
this system by refusing to decrypt a communication, if one 

jQ is somehow originated, in which the sender and recipient are 
in different countries and if either user is using a non-public 
master escrow center. These rules will effectuate the desired 
policy of disallowing unescrowed international crypto- 
graphic communications, because the master escrow center 

J 5 cannot falsify its public status, which is certified by the 
SWA, and, even if the master escrow center could falsify the 
user's country code (to make the user appear to belong in a 
foreign domain), the devices will not allow a discrepancy 
between the user's and the master escrow center's country 

2Q codes. Although these rules do not prevent a user from 
improperly transporting his trusted encryption device across 
national boundaries, they do allow easy comphance with 
national requirements by permitting him to maintain an 
escrowed key in each nation and to communicate using only 

25 the proper key in each policy domain. 
Multi-User Device Versions 

Another feature of this invention is the ability to initiate 
and simultaneously manage several different sessions of 
communications with different local or remote users using 

3Q the same device. Many larger computers support multiple 
users who are often simultaneously logged on via terminal 
sessions but who may wish to initiate encrypted sessions 
with other entities around the world. However, because it 
would be highly inefficient to require a separate trusted 

35 device for each user session on a shared computer, the 
trusted device could track the message session key for each 
communication by storing it along with a unique message 
sequence nimiber (MSN) for that session. Then, when any 
additional message packets bearing that MSN arrive, they 

4Q could be decrypted, and responses encrypted, without delay. 
Furthermore, the device could escrow the private decryption 
keys of several users while linking each user private key 
with a particular user unique identification number and 
allowing each key to be used only on presentation of some 

45 suitable user authentication, such as a password, smart card, 
PIN, biometric, challenge respoise, etc. By assigning a user 
identification number and password or the equivalent to each 
public/private key pair as it is generated for escrow, the 
usual controls on passwords, such as length, expiration, retry 

5Q lockouts and ease of guessing, could then be imposed by the 
device in order to limit the possibility of unauthorized 
access. 

Thus, a cryptographic system and method with key 
escrow feature is provided. One skilled in the art will 
55 appreciate that the present invention can be practiced by 
other than the described embodiments, which are presented 
for purposes of illustration and not limitation, and the 
present invention is limited only by the claims that follow. 

What is claimed is: 

1. A method for generating verifiably trusted, stream- 
oriented communications among a plurality of users, com- 
prising the steps of: 

escrowing at a trusted escrow center an asymmetric 
cryptographic key associated with each of a plurality of 
65 users; 

verifying each of the keys at the escrow center; 
certifying each of the keys upon verification; and 
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generatiag an encrypted stream -oriented communication 
from an initiating user to a receiving user using said 
initiating user's cryptographic key, said communica- 
tion comprising (a) an initial packet having access 
information to allow an outside parly to decrypt the 
stream, and (b) a stream of subsequent packets, each 
subsequent packet containing information identifying 
the subsequent packet as associated with the stream, 
and wherein at least one of said subsequent packets 
does not include said access information, 

2. The method of claim 1 wherein the communication 
further comprises a terminal packet having information 
indicating an end of the communication. 

3. The method of claim 1 wherein each subsequent packet 
further includes unique information indicating a position of 
the packet within the sequence. 

4. The method of claim 1 wherein each subsequent packet 
further includes timestamp information. 

5. The method of claim 1, wherein the access information 
includes a hash of the initial packet, 

6. The method of claim 5, wherein said hash of said initial 
packet is signed with the initiating user's cryptographic key. 

7. The method of claim 4, wherein said access information 
further includes message identifying information, 

8. The method of claim 7, wherein at least one of the 
subsequent packets includes the message identifying infor- 
mation . 

9. The method of claim 8, wherein said information 
identifying the subsequent packet as associated with the 
stream is a packet sequence number. 

10. The method of claim 1, further comprising the steps 

of: 

receiving, at the initiating user, information relating to a 
quality of a channel carrying the stream-oriented com- 
munication; and 

selectively including message identifying information in 
subsequent packets at a rate determined by the quality 
of the channel. 

11. The method of claim 1, wherein packets include 
information associating them with the initiating user. 

12. A method for generating verifiably trusted, stream- 
oriented communications among a plurality of users, com- 
prising the steps of: 

escrowing at a trusted escrow center an asymmetric 
cryptographic key associated with each of a plurality of 
users; 

verifying each of the keys at the escrow center; 
certifying each of the keys upon verification; and 
receiving, at a receiving user, a first encrypted stream- 
oriented communication from an initiating user, said 
communication having been encrypted using said ini- 
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tiating user's cryptographic key, said first communica- 
tion comprising (a) an initial packet having access 
information to allow an outside party to decrypt the 
stream, and (b) a stream of subsequent packets, each 
subsequent packet containing information identifying 
the subsequent packet as associated with the stream, 
and wherein at least one subsequent packet of the first 
stream does not include said access information. 

13. The method of claim 12 further comprising the steps 

of: 

generating a second encrypted stream-oriented commu- 
nication from the receiving user to an initiating user 
using a cryptographic key of the receiving user, said 
second communication comprising (a) an initial packet 
having access information to allow an outside party to 
decrypt the second encrypted stream, and (b) a stream 
of subsequent packets, each subsequent packet contain- 
ing information identifying the subsequent packet as 
associated with the second encrypted stream. 

14. The method of claim 13, wherein the access informa- 
tion of the second encrypted stream includes a hash of the 
initial packet of the second encrypted stream signed with the 
receiving user's cryptographic key. 

15. The method of claim 14, wherein the access informa- 
tion of the second encrypted stream includes message iden- 
tifying information received from the initiating user. 

16. The method of claim 15, wherein at least one of the 
subsequent packets of the second encrypted stream includes 
message identifying information. 

17. The method of claim 16, wherein the information 
identifying a subsequent packet of the second encrypted 
stream as associated with the second encrypted stream is a 
packet sequence number. 

18. The method of claim 17, wherein packets of the 
second encrypted stream include information associating 
them with the initiating user. 

19. The method of claim 13, further comprising the steps 

of: 

receiving, at the receiving user, information relating to a 
quality of a channel carrying the stream-oriented com- 
munication; and 

selectively including message identifying information in 
subsequent packets at a rate determined by the quality 
of the channel. 

20. The method of claim 19, wherein the information' 
relating to a quality of the channel is continuously received 
and the rate at which identifying information is selectively 
included in subsequent packets is dynamically adjusted 
based upon the received information. / 
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